Overview of Container Architecture
To understand container terminology, it’s very important to understand exactly what a container is — with technical precision. A container is really two different things. Like a normal Linux program, containers really have two states — rest and running. When at rest, a container is a file (or set of files) that is saved on disk. This is referred to as a Container Image or Container Repository. When you type the command to start a container, the Container Engine unpacks the required files and meta-data, then hands them off to the the Linux kernel. Starting a container is very similar to starting a normal Linux process and requires making an API call to the Linux kernel. This API call typically initiates extra isolation and mounts a copy of the files that were in the container image. Once running, Containers are just a Linux process. The process for starting containers, as well as the image format on disk, are defined and governed by standards.
Now lets talk about where technology behind container came from, Seems like its very new and existed since last 5/6 years , but in reality technology behind containers existed within Linux for a few decades, So you may have seen Red Hat people using slogan containers are Linux container are Linux, They are referring to there that lot of feature that built into Linux have created the space that are allowed container to become popular as they are and most of these features are built around containers needing to be isolated. So many years ago people realize that we need to find a way to isolate processes and this give rise to containers ,So what are these features in the Linux that helps containers exist..
1. Namespace: The kernel(kernel is able to isolate the resources from each other and from machine) can place specific system resources that are normally visible to all processes into a namespace. This isolates the resources.
2. Control groups(cgroups): This is going to limit the amount of resource group that the container can consume, So this will protect container to use all the resources in the host.
Container groups partition sets of processes and their children into groups and manage and limit the resources they consume.
3. Seccomp: Introduce to containers around 2014, Seccom limits how processes could use system calls.
4. SELinux: The Linux kernel uses SELinux to protect processes from each other and protect the host system from its running processes.
Now since we already discussed about containers, So now its good to talk about container architecture.
Containers: Containers are segregated user-space environment for running applications isolated from other applications sharing the same OS.
Image: Template for containers that include a runtime environment and all of the libraries and configuration files.
Think about the dishes and recipe, container is like and dish and image is like a recipe so by using recipe you can create multiple dishes, recipe is not going to change but you can always make little bit of adjustment to it but you can always be generating new and new recipe from there so in the same way that image to container relationship, Now let take the metaphor little further..
Image repository : Registries store images for public or private use, So image repository is like cookbook we can go through with the cookbook, look it all our recipe and pick up which we want to use and from that recipe we can generate lots of those containers or dishes.
So, there are multiple image repository that you can use right now below are some popular one.
- Red Hat Container Catalog
- Red Hat Quay
- Docker Hub
So, Now lets understand how to interact with these three things(registry, image and container)
How do we interact with containers, image and registry , To interact all of these we are going to use tool called Podman.
What is Podman?
Podman is open source tool for managing containers and container images and interacting with image registries. Its very similar to docker, Podman is also opensource tool which help to manage container, image and interact with registry
Podman uses image format specified by the Open Container Initiative (OCI). Those specifications defined as an standard, community-driven, non -proprietary image format.
Podman stores local images in local file-system. Doing so avoids unnecessary client/server architecture or having daemons running on local machine(podman is daemon less, opposite to that docker uses daemon).
Podman follows the same command patterns as the Docker CLI. Podman is also compatible with Kubernetes.
To install Podman in Red Hat Enterprise Linux, Fedora or similar RPM-based system, run $sudo yum install podman or sudo dnf install podman.
Let draw diagram here to tied up all concepts of container architecture..
Podman is going to interact with image repository, image and containers. Initially podman client will talk to image repository and download the image from repository, Once image is downloaded it will connect with image to create container, Once container created podman also do the container management. for example, getting the container start/stop/status etc.