Our story dates _all the way_ back to 2006, believe it or not. The first steps were taken towards what we know today as **containers**.
We'll discuss their history, how to build them and how to use them. Stick around! you might enjoy the ride.
<!--more-->
## History {#history}
### 2006-2007 - The _[Generic Process Containers](https://lkml.org/lkml/2006/10/20/251)_ lands in Linux {#2006-2007-the-generic-process-containers-lands-in-linux}
This was renamed thereafter to _[Control Groups](https://en.wikipedia.org/wiki/Cgroups)_, popularily known as _cgroups_, and landed in _Linux_ version `2.6.24`.
_Cgroups_ are the first piece of the puzzle in _Linux Containers_. We will be talking about _cgroups_ in detail later.
### 2008 - Namespaces {#2008-namespaces}
Even though _namespaces_ have been around since 2002, _Linux_ version `2.4.19`, they saw a [rapid development](https://www.redhat.com/en/blog/history-containers) beginning 2006 and into 2008.
_namespaces_ are the other piece of the puzzle in _Linux Containers_. We will talk about _namespaces_ in more details later.
### 2008 - LXC {#2008-lxc}
_LXC_ finally shows up!
_LXC_ is the first form of _containers_ on the _Linux_ kernel.
_LXC_ combined both _cgroups_ and _namespaces_ to provide isolated environments; containers.
<divclass="admonition note">
<pclass="admonition-title">Note</p>
It is worth mentioning that _LXC_ runs a full _operating system_ containers from an image.
In other words, _LXC_ containers are meant to run more than one process.
</div>
### 2013 - Docker {#2013-docker}
_Docker_ offered a full set of tools for working with _containers_, making it easier than ever to work with them.
_Docker_ containers are designed to only run the application process.
Unlike _LXC_, the `PID``1` of a Docker container is excepted to be the application running in the contanier.
We will be discussing this topic in more detail later.
## Concepts {#concepts}
### _cgroups_ {#cgroups}
#### What are cgroups ? {#what-are-cgroups}
Let's find out ! Better yet, let's use the tools at our disposal to find out together...
Open a **terminal** and run the following command.
```bash
man 7 cgroups
```
This should open the `man` pages for `cgroups`.
> Control groups, usually referred to as cgroups, are a Linux kernel feature which allow processes to be organized into hierarchical groups whose usage of various types of resources can then be limited and monitored. The kernel's cgroup interface is provided through a pseudo-filesystem called cgroupfs. Grouping is implemented in the core cgroup kernel code, while resource tracking and limits are implemented in a set of per-resource-type subsystems (memory, CPU, and so on).
#### What does this all mean ? {#what-does-this-all-mean}
This can all be simplified by explaining it in a different way.
Essentially, you can think of `cgroups` as a way for the _kernel_ to **limit** what you can **use**.
This gives us the ability to give a _container_ only **1** CPU out of the 4 available to the _kernel_.
Or maybe, limit the memory allowed to **512MB** to the container.
This way the container cannot overload the resources of the system in case they run a fork-bomb, for example.
But, `cgroups` do not limit what we can "_see_".
### _namespaces_ {#namespaces}
#### _Namespaces_ to the rescue ! {#namespaces-to-the-rescue}
As we did before, let's check the `man` page for `namespaces`
```bash
man 7 namespaces
```
> A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes. One use of namespaces is to implement containers.
Wooow ! That's more mumbo jumbo ?!
#### Is it really simple ? {#is-it-really-simple}
Let's simplify this one as well.
You can think of `namespaces` as a way for the _kernel_ to **limit** what we **see**.
There are multiple `namespaces`, like the `cgroup_namespaces` which _virtualizes_ the view of a process `cgroup`.
In other words, inside the `cgroup` the process with `PID`**1** is not `PID` on the **system**.
The `namespaces` manual page lists them, you check them out for more details. But I hope you get the gist of it !
### Linux Containers {#linux-containers}
We are finally here! Let's talk _Linux Containers_.
The first topic we need to know about is **images**.
#### What are container images ? {#what-are-container-images}
We talked before that _Docker_ came in and offered tooling around _containers_.
One of those concepts which they used, in docker images, is **layers**.
First of all, an image is a _file-system_ representation of a container.
It is an on-disk, read-only, image. It sort of looks like your _Linux_**filesystem**.
Then, layers on top to add functionality. You might ask, what are these layers. We will see them in action.
Let's look at my system.
```bash
lsb_release -a
```
```text
LSB Version: n/a
Distributor ID: ManjaroLinux
Description: Manjaro Linux
Release: 20.2.1
Codename: Nibia
```
As you can see, I am running `Manjaro`. Keep that in mind.
Let's take a look at the kernel running on this machine.
```bash
uname -a
```
```text
Linux manjaro 5.10.15-1-MANJARO #1 SMP PREEMPT Wed Feb 10 10:42:47 UTC 2021 x86_64 GNU/Linux
```
So, it's _kernel version_`5.8.6`. Remember this one as well.
<!--list-separator-->
-_neofetch_
I would like to _test_ a tool called `neofetch`. Why ?
- First reason, I am not that creative.
- Second, it's a nice tool, you'll see.
We can test `neofetch`
```bash
neofetch
```
```text
fish: Unknown command: neofetch
```
Look at that! We don't have it installed...
Not a big deal. We can download an image and test it inside.
#### Pulling an image {#pulling-an-image}
Let's download a docker image. I am using `podman`, an open source project that allows us to **use** containers.
<divclass="admonition note">
<pclass="admonition-title">Note</p>
You might want to run these commands with `sudo` privileges.
As you can see, we just successfully built the container. We also got a `hash` as a name for it.
If you were careful, I used the `&&` command instead of using multiple `RUN`. You **can** use as many `RUN` commands ase you like.
But be careful, each one of those commands creates a **layer**. The _more_ layers you create, the _more_ time they require to **download\*/\*upload**.
It might not seem to be a lot of time to download a few extra layer on one system. But if we talk about _container orchestration_ platforms, it makes a big difference there.
Let's examine the build a bit more and see what we got.
```text
STEP 1: FROM ubuntu:20.04
STEP 2: RUN apt-get update && apt-get install -y neofetch
```
The first step was to _download_ the base image so we could use it, then we added a **layer** which insatlled neofetch. If we list our **images**.
```bash
podman images
```
```text
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/neofetch-ubuntu 20.04 6486fa42efe5 5 minutes ago 241 MB
docker.io/library/ubuntu 20.04 f63181f19b2f 5 weeks ago 75.3 MB
```
We can see that we have `localhost/neofetch-ubuntu`. If we examine the `ID`, we can see that it is the same as the one given to us at the end of the build.
Now that we created a _brand-spanking-new_ image, we can run it.
```bash
podman images
```
```text
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/neofetch-ubuntu 20.04 6486fa42efe5 6 minutes ago 241 MB
docker.io/library/ubuntu 20.04 f63181f19b2f 5 weeks ago 75.3 MB
```
First we list our **images**. Then we choose which one to run.
```bash
podman run -it neofetch-ubuntu:20.04 neofetch
```
{{<figuresrc="/ox-hugo/container-neofetch-ubuntu.png"caption="Figure 1: Neofetch on Ubuntu"target="_blank"link="/ox-hugo/container-neofetch-ubuntu.png">}}
`neofetch` is installed in that container, because the **image** has it.
We can also build an image based on something else, maybe `Fedora` ?
I looked in [Dockerhub (Fedora)](https://hub.docker.com/%5F/fedora/) and found the following image.
```dockerfile
FROM fedora:32
RUN dnf install -y neofetch
```
We can duplicate what we did before real quick. Save file, run command to build the image.
{{<figuresrc="/ox-hugo/container-neofetch-fedora.png"caption="Figure 2: Neofetch on Fedora"target="_blank"link="/ox-hugo/container-neofetch-fedora.png">}}
## Conclusion {#conclusion}
Finally thought _before_ I let you go. You may have noticed that I used `Podman` instead of `Docker`. In these examples, both commands should be interchangeable.
Remember kids, _containers_ are cool! They can be used for a wide variety of things. They are great at many things and with the help of _container orchestration_ platforms, they can scale better than ever. They are also very bad at certain things. Be careful where to use them, how to use and when to use them. Stay safe and mainly have fun!
