says
Containers, and container technologies like Docker and Kubernetes, have become increasingly common tools in many developer toolkits. The core goal of containerization is to provide a better way to create, package, and deploy software in different environments in a predictable and manageable way.
In this article, we’ll take a look at what a container is, how it differs from other virtualization technologies, and its advantages in deployment and operation. If you just want a quick overview of the core concepts of containers, you can skip to the penultimate part of the container terminology.
What is a container?
Containers are an operating system virtualization technology used to package applications and their dependencies and run them in an isolated environment. Containers provide a lightweight way to package and deploy applications in a standard way across different types of infrastructures.
These characteristics of containers make them very attractive to development and operations personnel. Because containers can run consistently on any host that supports containers, developers can test the same software directly locally and then easily deploy it later to a full production environment. At the same time, Container Format ensures that your application’s dependencies are placed in the image, simplifying the manual part and publishing process. Because the host and platform running the container are common, you can standardize the infrastructure of container-based systems.
Containers are created from the container image, which contains the system, application, and container environment. Like creating a specific container template, the same image can be used to generate any number of running containers. This is similar to how classes and instances work in object-oriented programming: a single class can be used to create any number of instances, and a single container image can be used to create any number of containers. This analogy also applies to inheritance, because container images can be the parent of other custom container images. Users can download pre-built containers from external sources or build custom images as needed.
What is a Docker?
While Linux containers are a common technology that can be implemented and managed in different ways, Docker is by far the most common way to run builds and containers. It includes a series of tools that allow users to create container images, push or pull images from external image repositories, and run and manage containers in different environments. Suffice it to say, the container’s rapid popularity on Linux is largely due to Docker’s efforts since its release in 2013.
The Docker command line tool plays multiple roles. It acts as a process manager for the container workload to run and manage the container. In addition, it can create new container images by reading and executing dockerfiles or by taking snapshots of running containers. This command can also interact with the Docker Hub to pull new container images or push local images to save or publish them.
While Docker provides only one of many implementations on Linux, it makes the container world easier to access and has the most common solutions. Although open standards have been developed for containers to ensure interoperability, most container-related platforms and tools use Docker as their primary reference when testing and distributing software. Docker may not always be the highest performing solution for a given environment, but it can be one of the most popular testing options. In fact, for containers, while there are many other alternatives on Linux, Docker is usually the first to be studied, not without reason, given Docker’s ubiquity and influence over terms, standards, and tools in the container ecosystem.
How does the container work?
Understanding how containers work is helpful in discussing how they differ from virtual machines.
Virtual machine vs container
A virtual machine, or VMs, is a hardware virtualization technology that allows you to completely virtualize hardware or computer resources. A separate guest OPERATING system management virtual machine is completely separate from the OS running on the host system. On the host system, a piece of software called the hypervisor is responsible for starting, stopping, and managing virtual machines. Because VMS run as completely different computers, they do not affect the host system or other VMS under normal operating conditions. Therefore, VMS have great isolation and security. However, they also have disadvantages. For example, virtualizing an entire computer requires a large amount of resources for the VM. In addition, because the virtual machine is running on a separate guest operating system, virtual machine configuration and startup times can be quite slow. Also, because the virtual machine runs as a separate machine, administrators often need to use infrastructure-like management tools and processes to update and run the various environments.
In summary, virtual machines allow you to subdivide your computer’s resources into smaller individual computers, but the end result is not significantly different from managing a group of physical computers. As computers grow, the responsibilities of each host may become more centralized, but the tools, policies, and processes you use and the capabilities of your system may not change significantly.
Instead of virtualizing the entire machine, the container takes a different approach — virtualizing the operating system directly. It runs as a dedicated process managed by the host operating system kernel, but has a limited and tightly operated view of the system processes, resources, and environment. Containers exist on the shared system and operate as if they were on a fully controlled computer.
Rather than thinking of containers as full computers like virtual machines, the more common management containers are more similar to applications. For example, although you can bind an SSH server to a container, this is not the recommended pattern. Instead, debugging is typically performed through a logging interface, applying updates by rolling new images, and de-emphasizing service management in favor of managing the entire container.
These features mean that containers occupy the space between the strong isolation of virtual machines and the local management of traditional processes. Containers provide regionalized and process-centric virtualization that strikes a good balance between limitation, flexibility, and speed.
Linux Cgroups and namespaces
Linux control groups, or Cgroups, is a kernel feature that allows processes and their resources to be grouped, isolated, and managed as a unit. Cgroups are bound to processes and determine access to resources and provide mechanisms for managing and monitoring their behavior. They follow a hierarchical system that allows child processes to inherit their parent’s conditions and possibly impose further restrictions. Cgroups treats processes as a group and binds required functionality to them, limiting the resources they can access.
Another kernel function that containers rely on is the Linux namespace. Namespaces limit what processes can see the rest of the system. A process running inside a namespace cannot get any processes running outside the namespace. Because a namespace defines a unique context separate from the rest of the system, the namespace’s process tree needs to reflect that context. Inside the namespace, the main process becomes PID1 (Process ID1), traditionally reserved for the OS’s init system. Building a tightly operated virtual process tree in the namespace allows processes running inside the container to behave as if they were operating in a normal, unconstrained environment.
Advantages of containerization
We’ve already discussed some of the technologies that make containers possible, so let’s take a look at what their most important features are.
Lightweight virtualization
Containers are much more portable than hardware virtualization, which uses virtual machines. First, the container uses the kernel of the host system and runs as a partitioned process in that operating system, rather than virtualizing all hardware resources and running a completely separate operating system in that environment.
Second, from the host’s point of view, containers run like other processes, which means they can be started and stopped quickly and can use limited resources. In addition, the container can not only view and access a subset of the host’s process space and resources, but can also, in most cases, act as a completely independent operating system.
The container image itself can also be very small. Minimal mirroring enables the workflow that depends on pulling the latest image without significant delay. This is a requirement of many fault-tolerant, self-healing distributed systems.
Environmental isolation
Using Linux kernel features such as Cgroups and namespaces, containers can be isolated from the host environment. This provides a degree of functional limitation to prevent the container environments from interfering with each other.
While not powerful enough to be considered a complete security sandbox, this isolation does have its advantages. Because hosts and each container keep the software in a separate file system, it is easier to avoid dependencies and library conflicts. The network environment can be detached so that applications within a container can be bound to their native ports without fear of software conflicts in the host system or in other containers. Administrators can then choose how to map the container’s network to the host network as needed.
Standardize packaging formats and runtime goals
One of the most compelling advantages of a container is that it can unify and simplify the process of packaging and deploying software. Container images allow you to bind applications and all runtime requirements into a single cell that can be deployed across multiple infrastructures.
Inside the container, developers can install and use any library needed by their applications without worrying about interfering with the host system libraries. Dependencies are version-locked when the image is created. The container runtime can act as a standard, stable deployment platform, so developers don’t need to know which particular machine the container is running on. As long as the container runtime is operational and sufficient system resources are available, the container behaves as it would in a development environment.
Likewise, from an operations perspective, containerization standardizes the requirements of a deployment environment. Rather than configuring and maintaining a specific environment based on the language, runtime, and dependencies of the application, administrators can focus on maintaining common hosts that act as container platforms and allocating resource pools that these computers can access. All application-specific features in the binding container create a natural boundary between the concerns of the application and the concerns of the platform.
scalability
The established paradigm of containers allows you to extend your application with a relatively simple mechanism. Lightweight mirroring, fast startup times, creating tests and deploying “golden mirrors,” and standardized runtime environments make it possible to build highly scalable systems.
An extensible system is highly dependent on the application architecture and how the container images themselves are built. A design that works well with the container paradigm will take full advantage of the container format to achieve a good balance of speed, availability, and manageability. Service-oriented architectures, especially microservices, are popular in containerized environments because the decomposition of applications into discrete components with a centralized purpose makes development, extension, and updating easier.
Container terminology
Before we wrap up, let’s review some of the key terms we’ve introduced in this article, as well as some of the new terms you might encounter as you continue to learn.
** Containers: ** In Linux, containers are an operating system virtualization technology that packages applications and their dependencies and runs them in a separate environment.
** Container images: ** Container images are static files that define the behavior of file systems and specific container configurations. It also serves as a template for creating containers.
** Container choreography: ** Container choreography describes the processes and tools needed to manage container queues across multiple hosts. It typically uses a container platform to control scaling, fault tolerance, resource allocation, and scheduling.
Container runtime: The container runtime is a component that runs and manages containers on a host. The most basic requirement is usually the ability to configure containers from a given image, but many runtimes also bind other capabilities such as process management, monitoring, and image management. Docker includes a container runtime within the Docker command, but there are many other alternatives available for different use cases.
**Docker: **Docker was the first technology to successfully popularize the Linux container concept. Among them, Docker’s tool ecosystem includes Docker, a container runtime with a large number of containers and an image management feature, Docker-compose, a system for defining and running multi-container applications, and Docker Hub, a container image repository.
**Dockerfile: **Dockerfile is a text file that describes how to build a container image. It defines the basic image, the commands to run within the system, and how processes are started and managed while running within the container. While Dockerfile is not the only option, it is the most common format for defining container images, even without the Docker image build functionality.
**Kata Containers: **Kata Container is a way to use models, workflows, and tools to manage lightweight virtual machines that replicate the experience of using Containers. Kata Container seeks to reap the benefits of containers while providing greater isolation and security.
**Kubernetes: **Kubernetes is a powerful container choreography platform that manages clusters of container hosts and the workloads running on them. Kubernetes provides tools and abstractions to deploy, extend, monitor, and manage containers in a high-availability production environment.
**Linux Cgroups: **Linux Cgroups, or control groups, bind kernel functionality to processes and determine their access to resources. Containers in Linux are implemented using CGroups, making it easy to manage resources and individual processes.
**Linux namespaces: **Linux namespaces are a kernel feature used to limit the visibility of processes or cgroups to the rest of the system. Containers in Linux use namespaces to help isolate workloads and resources from other processes running on the system.
**LXC: **LXC is a form of Linux containerization that predates Docker and many other technologies, while also relying on many of the same kernel technologies. In contrast to Docker, LXC typically virtualizes the entire operating system rather than just running the processes of the application, which is more like a virtual machine.
** Virtual Machine: A ** virtual machine, or VMs, is a hardware virtual technology that simulates an entire computer. A complete OPERATING system (OS) installed on a VM can be used to manage internal components and access VM computing resources.
** Virtualization: ** Virtualization is the process of creating, running, and managing virtual environments or computer resources. Virtualization is a way of abstracting physical resources and is often used to split resource pools for different purposes.
Total knot
Containers are not magic bullets, but they do have some advantages over running software on bare metal or using other virtualization technologies. By providing a lightweight, functionally isolated, and development-rich tool ecosystem to help manage complexity, the container provides great flexibility and control during development and throughout its operational life cycle.