How to grasp Containers and Docker (Mega Thread) When I started using containers back in 2015, I thought they were tiny virtual machines with a subsecond startup time. It was easy to follow tutorials from the Internet on how to put your Python or Node.js app into a container...

But thinking of containers as of VMs is an extremely leaking abstraction. It doesn't allow you to judge: - what's doable and what's not - what's idiomatic and what's not - what's safe enough and what's not So, I started looking for the Docker implementation details.

Docker is a behemoth doing many different things. There is plenty of materials on Docker but: - it's either shallow and introductory container tutorials - it's something deeply technical and hard to follow for a newbie So, it took me a while to structure things in my head.

I find the following learning order helpful: 1. Containers (low-level Linux impl) 2. Images (why do you need them) 3. Managers (many containers, one host) 4. Orchestrators (many hosts, one app)

1. Containers are not VMs. A container is an isolated (namespaces) and restricted (cgroups, capabilities, seccomp) process.

To start a process you need to fork/exec an executable. But to start a containerized process, you need to prepare a box first - create namespaces, configure cgroups, etc. Container Runtime is a special kind of (lower-level) software to run containers. https://t.co/buTxawMHWt

Runc is the most widely used Container Runtime. It's a command-line tool! To run a container it needs a bundle: - a JSON file with container params (path to executable, env vars, etc) - a folder with an executable and other files (if any) to put into a container fs

Oftentimes, a bundle contains files that closely resemble a typical Linux distribution (/var, /usr, /lib, /etc, ...) When runc launches a container with such a bundle, the process inside sees its filesystem as a typical OS. But it's not required! https://t.co/shA6p4aRiE

2. Images aren't mandatory to run containers. You probably already noticed that. Container Runtimes just need normal folders. Images solve the storage and distribution problem efficiently. Not the launching problem. Read here how: https://t.co/J4Xf7IL6dc

In the popularized by Docker workflow, you need an image to start a container. The reality is actually reverse. You can start containers without images. But you cannot build images without running containers! Read here why: https://t.co/ngBhW38JNK

3. Containers are for efficient server packing. Much like real containers - they were invented to increase the amount of stuff a typical ship could take on board. A typical server now runs tens or hundreds of containers. Thus, they need to coexist. Hence, a manager is needed.

A Container Runtime focuses on a single container start. A Container Manager focuses on making many containers happily coexist on a single host. Pulling images, unpacking bundles, configuring the inter-container network, storing container logs, etc. https://t.co/VkKcKpBsJT

containerd is the most widely used container manager daemon. Much like runc, it started as a component of Docker but was extracted into a dedicated project. containerd can work with runc or any other runtime that implements the containerd-shim interface.

And we are ready to explain Docker! Docker has two parts. dockerd - a higher-level daemon sitting in front of containerd daemon. docker - a command-line client to interact with dockerd. Docker's task is to make the container workflows developer-friendly.

Docker can - build/pull/push/scan images - launch/pause/inspect/kill containers - create networks/forward ports - etc etc But there is a dedicated piece of software for each such task individually. Checkout - podman - buildah - skopeo - kaniko - etc

4. Coordinating containers running on different hosts is hard. Remember Docker Swarm? Docker was already quite monstrous when the multi-host container orchestration was added into the same daemon. One more Docker's responsibility...

Omitting the issue with the bloated daemon, Docker Swarm seemed nice. But another orchestrator won the competition. Kubernetes! Docker Swarm is either obsolete or in maintenance mode since ~2020.

Kubernetes joins multiple servers (nodes) into a coherent cluster. Every such node has a container manager on it. It used to be dockerd, but it's deprecated now. containerd and cri-o are two popular choices of slimmer container managers nowadays.

There is a lot of tasks for the container orchestrator. How to group containers into higher-level primitives (pods)? How to interconnect nodes with running containers into a common network? How to provide service discovery? et cetera, et cetera... https://t.co/5IUpaChCht

Containers, Kubernetes, and AWS ECS enabled teams to create isolated services more easily. It helped to solve lots of administrative problems, especially for bigger companies.

But it created lots of new tech problems that didn't exist on the traditional VM-based setups! Managing lots of distributed services turned out to be really hard. And that's how a Zoo of Cloud Native projects came to be. https://t.co/QDLjYUiAnA

Last but not least, don't forget to check out this article for more details on Containerization and Orchestration domains https://t.co/tFQcnnaWqt

My latest take on the nature of _standard_ containers https://t.co/HFABs8L9NW

Learning Containers - The Hard Way 👇 Turned the above thread into a detailed blog post with: - Recommended Containers Learning Path - 20+ links to in-depth container materials https://t.co/8pvDgGDq3M