Can Containers Really Ship Software?
This article goes into detail about container history, how containers work, and why software should be run on containers.
Join the DZone community and get the full member experience.Join For Free
A Brief History of Containers
The container concept started way back in 1979 with the inception of chroot on Version 7 Unix (thanks to Sanjiva for pointing this out). Later technologies like FreeBSB Jails, Linux vServer, Solaris Containers/Zones, and OpenVZ emerged. In the year 2006, Google introduced the Prcess Container concept for aggregating a set of processes together and sharing resources among them. Later, this was renamed to cgroups and merged into the Linux kernel (version 2.6.24).
In year 2008, LXC was introduced. It used cgroups and namespace features for providing container isolation. Around 2013, Google started an open-source project called LMCTFY (Let Me Contain That For You) for implementing a container manger. During the same period, a company called dotCloud started researching the same topic and introduced Docker. With the inception of Docker and the libcontainer project, Google put the LMCTFY project on hold and contributed its concepts and abstractions to libcontainer.
Later in 2013, the container concept became very popular with the innovative ecosystem built by Docker. LXC was out there for some time and was used by many large organizations. Still, it didn't get much traction as Docker did, perhaps due to the low-level APIs provided and the complexity of using it. After some time, a company called CoreOS initiated a separate container technology called Rocket. They said they wanted containers to be composable and have production-grade security as well as saying that image distribution needed to be federated, and, finally, the image format and runtime needed to be open. At the time of this writing, Docker and Rocket are the most popular container technologies.
How do Containers Work?
In general, containers make use of Linux kernel namespaces (ipc, uts, mount, pid, network and user), cgroups, Apparmor & SELinux profiles, Seccomp policies, and chroots for providing an abstraction layer on top of an existing kernel instance for creating isolated environments similar to virtual machines. The main difference between virtual machines and containers is that virtual machines need to run a guest operating system and containers don't. As a result. containers consume fewer resources and start in milliseconds.
Can Traditional Software Be Run on Containers?
The simplest answer is yes. Anything that can be run on a virtual machine can be run on a container. Containers provide almost all the features provided by virtual machines, such as dedicated IP addresses, volume mounting, resource management (CPU, memory, disk), SSH (containers provide SSH differently and its called exec), OS images, container images, etc. However unlike virtual machines, containers do not provide an init system — they are designed to run a single process inside a container. What if multiple processes are needed for running a single unit of a system? For example, log publisher process might be needed for publishing logs of a server to a central location. If so, containers can be grouped together and let them share the kernel namespaces such as disk, processes, users.
Nevertheless, to take the best out of the container world, software needs to be designed in a way to be able to start extremely fast, be more lightweight, operate as a composition of individual units, or rather adhere to microservices architecture (MSA). Otherwise, the end result would only gain very little.
Are There Any Container-Optimized Operating Systems Available?
Image source: CoreOS
Yes, CoreOS is a smaller, minimal Linux operating system optimized for containers. Traditional Linux distributions may contain unwanted software packages, and they may increase the attack surface. They may also increase the size of the OS image.
CoreOS has built a fresh Linux distribution by optimizing system packages needed. It also provides container runtimes, regular automatic OS updates, networking configurations and integrates with etcd (a distributed key/value store).
Can Windows-Based Software Also Run on Containers?
Image source: MSDN, Microsoft
As of year 2016 yes, Microsoft very recently completed a project on implementing container support for their Windows Server operating system, and it's now available for preview. It allows Windows users to run Windows-based containers by sharing a Windows kernel similar to Linux containers. In parallel to this effort, Docker implemented support for Windows containers — as a result, Docker can now run on Windows with native Windows container support.
Why Should I Run My Software on Containers?
Mainly because of the lower resource usage (meaning less cost): Say that some software needs 10 virtual machines to run. If so, it would need to allocate resources to run 10 operating system instances (each virtual machine would run an operating system instance). The same software can be run on 10 containers with maybe four container hosts, which would only need to run four operating system instances.
Less startup time: Containers start in milliseconds compared to 10-20 seconds taken by virtual machines, purely because of the faster operating system boot up time.
Layered container images: Compared to virtual machine images, container images are created using multiple layers. As a result, the image creation process and the bandwidth needed to transfer images are optimized.
Container image repositories: Container images can be hosted in container image repositories. Docker provides a public image repository called Docker Hub, and CoreOS provides one called Quay. Any organization can have their own private container repositories.
A large container ecosystem: Currently there is a considerably large ecosystem being developed around containers, and most widely used operating systems and software can be run on containers with few clicks/commands.
Aligns well with microservices architecture: Microservices is a software architecture pattern that allows software to be deployed as a composition of individual deployable units. As a result, each software unit can be managed and scaled separately depending on the required demand.
Published at DZone with permission of Imesh Gunaratne. See the original article here.
Opinions expressed by DZone contributors are their own.