A Linux container is a set of processes that are isolated from the rest of the system, running from a distinct image that provides all files necessary to support the processes. By providing an image that contains all of an application’s dependencies, it is portable and consistent as it moves from development, to testing, and finally to production.
To put a finer point on it, imagine you’re developing an application. You do your work on a laptop and your environment has a specific configuration. Other developers may have slightly different configurations. The application you’re developing relies on that configuration and is dependent on specific files. Meanwhile, your business has test and production environments which are standardized with their own configurations and their own sets of supporting files. You want to emulate those environments as much as possible locally, but without all of the overhead of recreating the server environments. So, how do you make your app work across these environments, pass quality assurance, and get your app deployed without massive headaches, rewriting, and break-fixing? The answer: Containers. The container that holds your application has the necessary configurations (and files) so that you can move it from development, to test, to production without all of the nasty side effects. Crisis averted–everyone’s happy.
That’s a simplified example, but Linux containers can be applied to problems in many different ways where ultimate portability, configurability, and isolation is needed. No matter the infrastructure—on-premise, in the cloud, or a hybrid of the two—containers meet the demand.
Isn’t this just virtualization?
Yes and no. Here’s an easy way to think about the two:
- Virtualization lets many operating systems run simultaneously on a single system.
- Containers share the same operating system kernel and isolate the application processes from the rest of the system.
What does this mean? For starters, having multiple operating systems running on a hypervisor, the software that makes virtualization work, isn’t as lightweight as using containers. When you have finite resources with finite capabilities, you need lightweight apps that can be densely deployed. Linux containers run from that single operating system, sharing it across all of your containers, so your apps and services stay lightweight and run swiftly in parallel.
A brief history of containers
The idea of what we now call container technology first appeared in 2000 as FreeBSD jail, a technology that allows the partitioning of a FreeBSD system into multiple subsystems, or jails. Jails were developed as safe environments that a system administrator could share with multiple users inside or outside of an organization. In a jail, the intent was that processes get created in a modified chrooted environment—where access to the filesystem, networking, and users is virtualized—and could not escape or compromise the entire system. Jails were limited in implementation and methods for escaping the jailed environment were eventually discovered.
But the concept was compelling.
In 2001, an implementation of an isolated environment made its way into Linux, by way of Jacques Gélinas’ VServer project. As Gélinas put it, this was an effort to run “several general purpose Linux server [sic] on a single box with a high degree of Independence and security.” Once this foundation was set for multiple controlled userspaces in Linux, pieces began to fall into place to form what is today’s Linux container.
Containers become practical
Very quickly, more technologies combined to make this isolated approach a reality. Control groups (cgroups) is a kernel feature that controls and limits resource usage for a process or groups of processes. And systemd, an initialization system that sets up the userspace and manages their processes, is used by cgroups to provide greater control over these isolated processes. Both of these technologies, while adding overall control for Linux, were the framework for how environments could be successful in staying separated.
Advancements in user namespaces provided the next step for containers. User namespaces “allow per-namespace mappings of user and group IDs. In the context of containers, this means that users and groups may have privileges for certain operations inside the container without having those privileges outside the container.” This is similar to the concept of a jail, but with the added security of further isolation of processes, rather than jails’ concept of the modified environment.
The Linux Containers project (LXC) then added some much-needed tools, templates, libraries, and language bindings for these advancements–improving the user experience when using containers.
In 2008, Docker came onto the scene (by way of dotCloud) with their eponymous container technology. The docker technology combines the work of LXC with further-improved tools for developers, increasing the user-friendliness of containers. Docker, an open source technology, is currently the most well-known project and method for deploying and managing Linux containers.
Today Red Hat and Docker, among many others, are members of the Open Container Initiative (OCI)—working toward open industry standardization of container technologies.
Standardization and the Open Container Initiative
The Open Container Initiative (OCI), part of the Linux Foundation, was launched in 2015 “for the express purpose of creating open industry standards around container formats and runtime.” This project is focused on determining and setting specifications–currently two specs: Runtime and Image.
The Runtime Specification sets open standards around a filesystem bundle, the structure of supporting files and artifacts in a container, and how that bundle is unpacked by a compliant runtime. Basically, the spec exists to make sure containers work as intended and that all supporting assets are available and in the correct places.
OCI’s Image Specification defines how container images are created. This creation outputs “an image manifest, a filesystem serialization, and an image configuration.”
These specifications work together to define what’s in a container image and its dependencies, environments, arguments, etc. necessary for the image to be run properly.
Containers are an abstraction
Linux containers are another evolutionary leap in how we develop, deploy, and manage applications. Linux container images provide portability and version control, helping ensure that what works on a developer’s laptop also works in production.
A running Linux container is less resource intensive than a virtual machine, but retains much of the application isolation, and is more easily managed as part of a larger application.
The point of Linux containers is being able to develop faster and meet business needs as they arise, rather than the which software you’re using to do that work. Don’t limit yourself to thinking of containers as holding the single application: You can use containers to hold parts of an application or services. Then you can use other technologies, such as Kubernetes, to automate and orchestrate your containerized apps. A container hosts application logic, a runtime, and dependencies, so your container can include everything, or you can build an application that comprises many containers working as microservices.
Containers in production environments
Containers are a great way to deliver software and applications to your customers faster. That means using them in production environments. And that means higher stakes for the processes running on those containers.
Fortunately Red Hat’s there to help. Red Hat has a long history of working in the open source community to make technologies–like containers–secure, stable, and reliable. It’s what we do. Then we support those technologies. So if you need help, we’re there.
Red Hat’s technologies take all of the guesswork out of doing containers the right way. Whether it’s getting your development teams on a platform built with containers in mind, running your container infrastructure on a best-in-class operating system, or providing storage solutions for the massive data generated by containers, Red Hat’s solutions have you covered.