Published on: July 30, 2019 by Galvin Sam
Scenario:
Consider a scenario in which you are a developer and you are developing an application on your local machine and you are working on an environment with a specific configuration. Meanwhile, the production server on which the application is to be deployed is running on an environment with a different configuration. This creates a conflict between the development and the operations team.
Linux containers help reduce conflicts between your development and operations teams by separating areas of responsibility. Developers can focus on their apps and operations can focus on the infrastructure. And, because Linux containers are based on open source technology, you get the latest and greatest advancement as soon as they’re available.
Linux Container is a set of one or more processes that are isolated from the rest of the host system. All the files that are necessary to run a Linux Container are provided from distinct images which makes a Linux Container portable and consistent as they move from different phases in a production environment such as development, testing and finally to production.
Linux container not only reduces the conflict between different application running environment. Linux containers have also sparked an interest in microservice architecture. Microservice architecture is a design pattern for developing applications in which complex applications are broken down into smaller, composable pieces which work together. Each component is developed separately, and the application is then simply the sum of its constituent components. Each piece, or service, can live inside of a container and can be scaled independently of the rest of the application as the need arises.
Why Linux container?
A question may arise, why choose Linux container over a Virtual Machine?
Yes, for reducing the conflict between the application running environment, definitely Virtual Machine is a good option. When an application is composed of only smaller numbers of large components, it’s completely acceptable to give a dedicated Virtual Machine (VM) to each component and isolate their environments by providing each of them with their own operating system instance. But when these components start getting smaller and their numbers start to grow, you can’t give each of them their own VM if you don’t want to waste hardware resources and keep your hardware costs down. But it’s not only about wasting hardware resources. Because each VM usually needs to be configured and managed individually, rising numbers of VMs also lead to wasting human resources, because they increase the system administrators’ workload considerably.
Comparing containers to virtual machines, containers are much more lightweight than virtual machine as the virtual machines need to run their own set of system processes which requires additional computing resources in addition to those consumed by the component’s own process. A container, on the other hand, is nothing more than a single isolated process running in the host OS, consuming only the resources that the app consumes and without the overhead of any additional processes.
Because of the overhead of VMs, you often end up grouping multiple applications into each VM because you don’t have enough resources to dedicate a whole VM to each app. When using containers, you can (and should) have one container for each application. The end result is that you can fit many more applications on the same bare-metal machine.
Using VMs to isolate groups of applications vs. isolating individual apps with containers
When you run three VMs on a host, you have three completely separate operating systems running on and sharing the same bare-metal hardware. Underneath those VMs is the host’s OS and a hypervisor, which divides the physical hardware resources into smaller sets of virtual resources that can be used by the operating system inside each VM. Applications running inside those VMs perform system calls to the guest OS kernel in the VM, and the kernel then performs on the host’s physical CPU through the hypervisor.
The difference between how apps in VMs use the CPU vs. how they use them in containers.
Containers, on the other hand, all perform system calls on the exact same kernel running in the host OS. The CPU doesn’t need to do any kind of virtualization the way it does with VMs (see above figure).
The main benefit of VM is the full isolation they provide, because each VM runs its own Linux kernel and their own set of system services, while containers call out to the kernel of the parent machine or the node on which the container is created. Compared to VM, containers are exceptionally lightweight, megabytes in size and will take only seconds to start versus gigabytes and minutes for a VM. If you have a greater number of processes to be isolated on the same host machine, containers are a much better choice because of their low overhead.
Category : Linux
Add new commentSIGN IN