DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
There are some questions about containers, such as:
My questions:
The very first thing to know about a container is:
It is, first and foremost, a process.
Once that is understood, one can start to understand how containers compare and contrast with virtual machines. Containers and VMs both share isolation from their hosts. The method of isolation is the critical difference.
Container processes use extensions to the OS kernel host on which they run to isolate themselves from other processes. Other extensions also provide disk and resource isolation. Containers share their kernel and memory with the host OS.
Virtual Machines use a hypervisor to isolate VMs from their hosts. This is a layer of software that forwards requests for resources from "guests" (VMs) to the hardware. Disk isolation is provided by disk virtualization. VMs do not share a kernel with the host- they load their own kernels into memory space dedicated to the VM.
One important impact of this difference is that a container must be kernel-compatible with its host. For example, it is not possible to run a Windows Nano Server-based container on a Linux host, or an Ubuntu container directly on a Windows host. Virtual Machines, by contrast, can run any kernel regardless of host OS. When running a Linux container on a Windows host, Docker runs the container in a Linux VM.
The operational differences are in agility: containers start and stop about as fast as a normal process. VMs are "heavier," requiring dedicated resources set aside for them and take longer to start and shut down.
Containers offer a lot of flexibility to a DevOps operating model:
The word container refers to a lightweight virtualisation technology available on modern Linux kernels, this technology is very similar to FreeBSD jails.
An older, non-container-able, Linux kernel is able to run processes concurrently. Some attributes of the system are private to process, like the process environment or the process memory: only the process owning these attributes and the operating system itself are able to access to this data. (There is a lot of loopholes, like some ps implementations, but that's essentially true!) Some other attributes are shared among the processes, like the filesystem and network interfaces for instance.
A modern, container-able, Linux kernel is able to handle more attributes of the system as private data associated to a process or a group of processes. The resulting context is a container and instead of running a program in the “initial containers” using the filesystem and the network interfaces initialised by the operating system, it is possible to run processes in other containers, so that they see a different filesystem and a different list of network interfaces. Therefore, two processes running in distinct containers only really share the kernel. You are maybe familiar with the chroot command which can run a process in a distinct file-hierarchy, containers take the idea a few step further.
Of course, this is just a very coarse explanation, but I hope it helps to clarify the idea of what containers are. Now, what are they good for?
A popular interface to the container capabilities of Linux kernels is implemented by docker, a command-line utility that can be used to produce artefacts representing file-systems (docker images) and run processes in containers where these file-systems are accessible. This software suite is also able to build ad-hoc virtual networking systems to let several containers communicate on a private network.
Container-based technologies are convenient to:
(As you seem familiar with other virtualisation technologies like Virtual Box, you might remark that these technologies can also conveniently address the three points above. Nowadays, there is quite a small spectrum of virtualisation technologies, and we can compare the question of their popularity in certain contexts with the popularity of computer languages: it depends probably of the technical merits of each individual solution, but also to a lot of factors that I will just label “chance”.)
Usually containers refers to something like docker containers which have popularized the name
I quote there from docker definition:
Using containers, everything required to make a piece of software run is packaged into isolated containers. Unlike VMs, containers do not bundle a full operating system - only libraries and settings required to make the software work are needed.
The root naming comes linux containers (lxc) whose goal was to isolate a process from its host system, the first goal was to avoid compromission of the process to take over the host system.
Now they are used in a wider scope. In a modern 'container' definition, you'll more or less release a package for runtime which already include your application, it's underlying middle-ware if needed and all necessary libraries and be sure it will run on any compatible system.
The second advantage is that it allows to use multiple applications with the same dependency at different version without having to heavily tweak its environment variables so it load the correct one.
Unlikely to a VM system like virtual box virtual machine or an EC2 instance on AWS, containers are virtual only on the file system level and isolated only on the memory stack. They still share the same host and the operating system under them will arbitrate cpu ticks.
A virtual machine is virtual at the hardware level, and you run an operating system within, a container is virtual at the OS level, and your run a process within.
From AWS's definition:
Containers are a method of operating system virtualization that allow you to run an application and its dependencies in resource-isolated processes. Containers allow you to easily package an application's code, configurations, and dependencies into easy to use building blocks that deliver environmental consistency, operational efficiency, developer productivity, and version control. Containers can help ensure that applications deploy quickly, reliably, and consistently regardless of deployment environment. Containers also give you more granular control over resources giving your infrastructure improved efficiency.
Containerizing is packing all the essential necessities needed for doing a particular task/environment so that it is self-sufficient and can be run on any platform, which takes away a lot of pain, when it comes to setting up and installing stuff.
