The history of Linux container technology: from Chroot to the future

The Linux container is an operating system-level virtual technology that provides multiple isolated Linux environments on a single Linux host. Unlike virtual machines (VMS), containers do not need to run a dedicated guest operating system. Containers share the host operating system kernel and use the Guest OS's system library to provide the required functionality. Because there is no need for a dedicated operating system, containers are much faster to boot than a virtual device.

Virtual Machines Vs Containers

(Photo from: Docker Inc)

Reproduced in: http://www.itxuexiwang.com/a/liunxjishu/2016/0228/178.html?1456925793

Containers provide a virtual machine-like isolation environment with features such as the namespaces, Apparmor, SELinux profile, chroot, and CGroup of the Linux kernel. The Linux security module ensures proper control of the container's access to the host and the kernel, thus avoiding various intrusion activities. In addition, different Linux distributions can be run on the host as long as they run under the same CPU architecture.

Simply put, the container provides a way to create a container image based on a variety of Linux distributions, a set of APIs to manage the lifecycle of the container, client tools to interact with the API, the ability to save snapshots, the capability to migrate container instances between hosts, and so on.

Container history

The following is a brief history of containers from Wikipedia and other sources:

1979-chroot

The concept of a container began with the 1979 UNIX chroot, a system call on a UNIX operating system that was used to change the root of a process and its child processes to a new location in the file system, allowing those processes to access only that directory. The idea of this feature is to provide separate disk space for each process. Later in 1982, it was added to the BSD system.

2000-freebsd jails#p# pagination Title #e#

The FreeBSD jails is one of the earliest container technologies, which was introduced to FreeBSD by the R & R Associates Company's Derrick T Woolworth in 2000. This is an OS-level system call similar to Chroot, but the process sandbox functionality is added to the isolation of file systems, users, networks, and so on. Therefore, it can specify an IP address for each jail, can customize the installation and configuration of the software, and so on.

2001-linux VServer

Linux VServer is another jail mechanism that is used to safely partition resources on a computer system, such as file systems, CPU processing time, network addresses, and memory. Each partition is called a security context, in which the virtual system is called a virtual private server (SERVER,VPS).

2004-solaris Containers

The Solaris Containers support on x86 and SPARC systems, first appeared in the February 2004 build of Solaris 10 Beta, which was released in 2005 on Solaris 10. The Solaris Container is a combination of system resource control and boundary separation (boundary separation) provided by zones. Zones is a fully isolated virtual server in a single operating system instance.

2005-openvz

OpenVZ is similar to the Solaris Containers, which provides virtualization, isolation, resource management, and stateful inspection (checkpointing) by patching the Linux kernel. Each OpenVZ container has a set of isolated file systems, users and user groups, process trees, networks, devices, and IPC objects.

2006-process Containers

Process Containers was implemented by Google in 2006 to limit, account for, and isolate resource usage (CPU, memory, disk I/O, network, etc.) for a set of processes. It was later renamed Control Groups to avoid confusion with the word "container" in the context of the Linux kernel. It was incorporated into the 2.6.24 kernel. This suggests that Google has long been involved in the development of container technologies and how they have been fed back into the community.

2007-control Groups

As mentioned above, Control Groups (that is, cgroups) is implemented by Google and added to the Linux kernel in 2007. #p # pagination Title #e#

2008-lxc

LXC means Linux Containers, which is the first implementation of the most complete Linux container manager, implemented through Cgroups and the Linux namespace (namespace). LXC exists in the LIBLXC library and provides API implementations for a variety of programming languages, including Python3, Python2, Lua, Go, Ruby, and Haskell. Unlike other container technologies, LXC can work on a common Linux kernel without the need to add patches. LXC Project is now sponsored and hosted by Canonical Corporation.

2011-warden

Warden was developed by Cloudfoundry in 2011, and the start-up phase was the use of LXC, after which they were replaced with their own implementation scenarios. Unlike Lxc,warden, which is not tightly coupled to Linux, it can work on any operating system that can provide an isolated environment. It runs as a daemon and provides APIs for container management. Please refer to the Warden documentation and this blog post for more information.

2013-lmctfy

Lmctfy means, "Let me include (letting me contain that for you)." This is an open source version of Google container technology that provides a Linux application container. Google launch This project is designed to provide performance-assured, highly resource-efficient, resource-shared, oversold containers that are nearly 0 consumed (refer to: Lmctfy speech). The Cadvisor tool for Kubernetes is now starting with the results of the LMCTFY project. Lmctfy was first released in October 2013, and in 2015 Google decided to contribute to the core LMCTFY concept and abstracted it into Libcontainer, so lmctfy is no longer active in development.

The Lincontainer project was originally initiated by Docker and has now been handed over to the Open Container Foundation (Container).

2013-docker

Docker is by far the most popular and widely used container management system. It was originally an internal project of a PaaS service company called DotCloud, which later changed its name to Docker. Similar to the beginning of the warden,docker use of LXC, and then the use of their own development of Libcontainer instead of it. Unlike other container platforms, Docker introduces an entire ecosystem of management containers, including efficient, tiered container mirroring models, global and local container registries, clear REST APIs, command lines, and more. Later in the phase, Docker pushed for a container cluster management solution called Docker Swarm.

2014-rocket#p# Pagination Title #e#

Rocket is a project initiated by CoreOS, very similar to Docker, but fixes some of the problems found in Docker. CoreOS says their aim is to provide a more stringent security and product requirements than Docker. More importantly, it is implemented in a more open standard APP Container specification. Outside of Rocket, CoreOS also developed several other container-related products for Docker and kubernetes, such as CoreOS operating systems, ETCD, and flannel.

2016-windows Containers

Microsoft also added container support for Windows-based apps on Windows Server in 2015, which it calls Windows Containers. It is published with Windows Server 20,161. With this implementation, Docker can natively run Docker containers on Windows without having to start a virtual machine to run Docker (a Linux virtual machine is required to run Docker on Windows earlier).

The future of the container

As of today (January 2016), there is a significant trend in the industry, where deployment software applications are gradually moving from virtual machines to containers. The main reason is that containers are more flexible and less low-consumption than virtual machines. Google has been using container technology for years, and it can run Google Apps on a scale in the Borg and Omega container cluster management platforms. More importantly, Google has contributed cgroups implementations and participated in the Libcontainer project for the container sector. In the past years, Google has also made significant gains in performance, resource utilization, and overall efficiency through the use of containers. Recently, Microsoft, which has no operating system-level virtualization technology, has also taken swift action on Window Server to implement native support for containers.

Docker, Rocket, and other container platforms do not operate in a single host in a production environment, because they are facing a single point of failure. When a set of containers is running on a single host, all containers running on that host are invalidated if the host fails. To avoid this problem, you should use the container host cluster. With its experience in Borg, Google has developed an open-source container cluster management system called Kubernetes. Docker also launched a solution called Docker Swarm. These solutions are still at a very early stage, and may take months or years to achieve a complete set of functions to become stable and thus widely used in the industry's product environment.

MicroServices (MicroServices) is another breakthrough technology that allows containers to be deployed on software architectures. MicroServices are not a new thing, just a lightweight web service that is super fast compared to standard Web services. This is achieved by packaging a functional unit (perhaps a single service or API method) into a service and embedding it into a lightweight Web server software. #p # pagination Title #e#

With this introduction, we can predict that in the next few years, containers might replace virtual machines, and in some cases they might all be replaced. Last year I implemented a container-based solution for some companies at the POC level. Others want to try them in a product environment, a day that may come soon after the container cluster management system matures.

The history of Linux container technology: from Chroot to the future