What’s a Linux container?
A Linux® container is a set of 1 or more processes that are isolated from the rest of the system. All the files necessary to run them are provided from a distinct image, meaning Linux containers are portable and consistent as they move from development, to testing, and finally to production. This makes them much quicker to use than development pipelines that rely on replicating traditional testing environments. Because of their popularity and ease of use containers are also an important part of IT security.
Why use Linux containers?
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 libraries, dependencies, and files. Meanwhile, your business has development and production environments that 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 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 libraries, dependencies, and files so you can move it through production without nasty side effects. In fact, the contents of a container image—created using an open-source tool like Buildah—can be thought of as an installation of a Linux distribution because it comes complete with RPM packages, configuration files, etc. But, container image distribution is a lot easier than installing new copies of operating systems. Crisis averted—everyone’s happy.
That’s a common example, but Linux containers can be applied to many different problems where portability, configurability, and isolation is needed. The point of Linux containers is to develop faster and meet business needs as they arise. In some cases, such as real-time data streaming with Apache Kafka, containers are essential because they’re the only way to provide the scalability an application needs. No matter the infrastructure—on-premise, in the cloud, or a hybrid of the two—containers meet the demand. Of course, choosing the right container platform is just as important as the containers themselves.
Red Hat® OpenShift® includes everything needed for hybrid cloud, enterprise container, and Kubernetes development and deployments. OpenShift is available as a cloud service with major cloud providers, or you can manage OpenShift yourself for greater flexibility and customization.
Isn’t this just virtualization?
Not exactly. Think of them more as complementary of one another. Here’s an easy way to think about the 2:
- Virtualization lets your operating systems (Windows or Linux) run simultaneously on a single hardware system.
- Containers share the same operating system kernel and isolate the application processes from the rest of the system. For example: ARM Linux systems run ARM Linux containers, x86 Linux systems run x86 Linux containers, x86 Windows systems run x86 Windows containers. Linux containers are extremely portable, but they must be compatible with the underlying system.
What does this mean? For starters, virtualization uses a hypervisor to emulate hardware, which allows multiple operating systems to run side by side. This 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 natively on the operating system, sharing it across all of your containers, so your apps and services stay lightweight and run swiftly in parallel.
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 special type of container image called a golden image creates a consistent, reliable baseline for system configuration. Compared to virtual machines, a running Linux container is less resource-intensive, has a standard interface (start, stop, environment variables, etc.), retains application isolation, and is more easily managed as part of a larger application (multiple containers). Plus, those multi-container applications can be orchestrated across multiple clouds.
There are even tools that combine container orchestration and virtual machine management. Learn more about that in this Red Hat Summit 2020 track, which includes a breakout session on just such a tool.
What is LXC?
The Linux Containers project (LXC) is an open source container platform that provides a set of tools, templates, libraries, and language bindings. LXC has a simple command line interface that improves the user experience when starting containers.
LXC offers an operating-system level virtualization environment that is available to be installed on many Linux-based systems. Your Linux distribution may have it available through its package repository.
A brief history of containers
The idea of what we now call container technology first appeared in 2000 as FreeBSD jails, 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 2001, an implementation of an isolated environment made its way into Linux, by way of Jacques Gélinas’ VServer project. 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.
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.
Enter Docker
In 2008, Docker came onto the scene (by way of dotCloud) with their eponymous container technology. The docker technology added a lot of new concepts and tools—a simple command line interface for running and building new layered images, a server daemon, a library of pre-built container images, and the concept of a registry server. Combined, these technologies allowed users to quickly build new layered containers and easily share them with others.
There are 3 major standards to ensure interoperability of container technologies—the OCI Image, Distribution, and Runtime specifications. Combined these specifications allow community projects, commercial products, and cloud providers to build interoperable container technologies (think pushing your custom built images into a cloud provider’s registry server — you need that to work). Today Red Hat and Docker, among many others, are members of the Open Container Initiative (OCI)—are enabling an open, industry standardization of container technologies.