Docker vs. containerd vs. Podman 🧵

Containers are everywhere, and Docker is the most popular (and user-friendly) way of running them. But it's definitely not the only way!

I prepared a series of exercises to help you explore the alternative single-host runtimes 👇 To set up a baseline, I recommend starting with Docker.

Try launching a container and inspecting it:

- What is it exactly that you just launched?
- Is it a single process? A lightweight VM?
- Can you find the IP address of the container?

labs.iximiuz.com/challenges/sta…

What Actually Happens When You Publish a Container Port? Mini-🧵

docker run -p 8080:80 nginx

Have you ever wondered what `-p 8080:80` in the above command does? Then read on! When you launch Nginx (or any other service), it opens a socket on a certain address - e.g., 172.17.0.3:80.

Clients that can reach this IP address can access the service.

How Container Networking Works 🧵

1. Network namespaces - a Linux facility to virtualize network stacks.

Every container gets its own isolated network stack with (virtual) network devices, a dedicated routing table, a scratch set of iptables rules, and more. 2. Virtual Ethernet Devices (veth) - a means to interconnect network namespaces.

Container's network interfaces are invisible from the host - the latter runs in its own (root) network namespace.

To punch through a network namespace, a special Virtual Ethernet Pair can be used.

What is Service Discovery - in general, and in Kubernetes 🧵

Services (in Kubernetes or not) tend to run in multiple instances (containers, pods, VMs). But from the client's standpoint, a service is usually just a single address.

How is this single point of entry achieved? 1⃣ Server-Side Service Discovery

A single load balancer, a.k.a reverse proxy in front of the service's instances, is a common way to solve the Service Discovery problem.

It can be just one Nginx (or HAProxy) or a group of machines sharing the same address 👇

What Happens When You Publish a Container's Port? 🧵

"Port publishing" might be a term coined by Docker.

But "port forwarding" or "port mapping" - as a form of socket redirection - was a widespread trick well before the invention of containers. How are the two different? Learn about different port forwarding techniques and how container runtimes implement them in this heavily illustrated blog post 👇

- Docker Engine
- Docker Desktop
- containerd
- nerdctl
- Lima

iximiuz.com/en/posts/docke…

🧵 Efficient Learning Path to Master Containers 📚

1/ When I started with Docker in 2015, I viewed containers as lightweight VMs with fast startups. But this oversimplified view posed risks:

- Misunderstanding capabilities
- Misusing the technology
- Misjudging safety means 2/ The "container = VM" simplification was helpful at first but it quickly became inadequate.

To truly understand what I can and cannot do with containers, I had to dive deep into Docker's internals. However, available materials were either too basic or too complex.

[not a] Kubernetes 101 🧵

Kubernetes Pods, Deployments, and Services As an Attempt To Automate Age-Old Infra Patterns

Let's track the web service evolution from a single instance running on a VM to a highly available multi-node system... first without and then with Kubernetes. 1. Running a single process on just one server.

The simplest possible (self-hosted) setup. Can be a regular process controlled by a supervisor(d), a systemd service, or even a Docker container.

Easy, addressable, but not production-ready yet.

Ever wanted to learn how to work with the Kubernetes API? I've got something for you! 🧵

A thread with a bunch of resources to help you:

- Grasp the main API concepts
- Access the API from the command line
- Call it from a Go program
- Prepare to write your first controller 👇 1. Learn the Kubernetes API Basics - Resources, Kinds, and Objects

There are many moving parts, but it's relatively well structured and consistent, so you may even like the design in the end!

iximiuz.com/en/posts/kuber…

From VMs to Containers to Pods 🧵

Containers are (just) Linux processes.

A helpful approximation to "get it." But at some point it might start limiting one’s understanding of the tech, hence the abilities. Containers are a lightweight VM replacement.

Another good approximation. Helps to see the problem from a slightly different angle. But the thing is that some containers are actually VMs (Kata Containers, for example).

Understanding Kubernetes Through VMs: A Thread 🧵

1/ 🚀 Starting with Kubernetes can be daunting. But instead of jargon-loaded explanations, let's understand Kubernetes as a natural evolution of traditional deployment techniques. 2/ 🤔 Ever deployed services using virtual machines (VMs)? If so, you'll find Kubernetes not so different.

Back in 2010, deploying with VMs (sometimes even bare-metal) was common. Think of a service as a "named group of identical machines." This was our traditional method.

A thread on Desktop Container Environments 🧵

We'll peek into the inner workings of running cross-platform containers and discover some exciting tools like OrbStack and Lima!

Get ready for a fascinating journey! 🚀 Picture this: You want to run a [Linux] container on your macOS or Windows. You'll need a Virtual Machine because only a real Linux kernel can provide the building blocks - namespaces and cgroups

Who does the job of VM provisioning? Say hello to Desktop Container Environments 🏗️

I've been solo-building a pet project for a few months, and I'm pleasantly surprised by how much a hardcore backend engineer can achieve with the modern frontend stack! 💪

A thread on tools and tricks that helped me to develop a Web UI for iximiuz Labs 🧵 1. Learn CSS Flexbox Layout.

The only thing that I remember from my past fullstack experience 2012-2016, is how CSS just didn't make any sense to me... Centering a div was a real challenge.

Flexbox is intuitive!

- Memo css-tricks.com/snippets/css/a…
- Theory joshwcomeau.com/css/interactiv…

Want to master Docker and become a container expert
...but don't know how to even start? 🔽

Here is the learning order that helped me:

1. Containers: how Linux does them
2. Images: why they are needed
3. Managers: many containers, one host
4. Orchestrators: many hosts, one app Following high-level Docker tutorials and how-tos kept me thinking containers are just lightweight virtual machines for quite a while.

Looking at you "docker run -it debian bash" 👀

In actuality, most containers are just regular (but isolated and restricted) Linux processes.

How To Grasp Container Networking 🧵

A tricky topic... Container networking can feel like magic at times. But it's not!

Rather it's a bunch of more primitive "LEGO bricks" like net namespaces, veth pairs, and bridges combined into a handy (but complex) higher-level abstraction. Through the networking lens, every container represents a tiny little server with its own IP address.

Containers on a single host are attached to the same bridge (aka virtual switch) and can talk to each other on L2 (Ethernet) and L3 (IP) layers.

More 👇 iximiuz.com/en/posts/compu…

How To Publish a Port of a Running Container 🧵

Docker (rightfully) doesn't allow that. So, what are the options?

- Restart it, potentially from a committed state 🥱
- Modify container's configs and restart dockerd 🙈
- Call <container_ip>:<port>
- Write some iptables

...or 👇 Brush up your containers and networking skills and create an elegant solution!

- Containers in the same network can talk to each other using their IP addresses
- You can "connect" any two sockets using a user-space proxy like socat

Solution: create a helper forwarder sidecar!

What Happens When You Publish a Container's Port? 🧵

"Port publishing" seems to be a term coined by Docker.

But "port forwarding" aka "port mapping - as a form of socket redirection - was a well-known trick well before the invention of containers.

How are the two different? First, a little bit of computer networking theory 🤓

There are two main ways to "redirect sockets":

- With a two-sided proxy forwarding payload data only
- With an L3 packet modification (dest address change)

Port forwarding can be implemented in user- and kernel space.

Why I wrote yet another container debugger 🧵

I work with containers a lot, and they often misbehave. My typical debugging needs include:

- Running an interactive shell in a container
- Using not-installed debugging tools
- Forwarding container ports to the host system
- etc. I researched the available tools and non of them satisfied my needs fully.

My criteria:

- Portability: one tool for many runtimes (docker, containerd, k8s).
- Completeness: one tool for exec, net, and fs use cases.
- Unified UX: different runtimes but same command behavior.

Computer Networking For Developers 🧵

Need to get into networking but all materials you find feel like they are written for bearded networking gurus?

I've got a bunch of "different" articles for you! Written by a developer for fellow developers 👇 1. Computer Networking Introduction: Ethernet and IP

A heavily-illustrated comic-like article - a foundation for further learning. I wish I had something like it when I was studying the networking basics in college.

With a bunch of easy-to-follow labs!

iximiuz.com/en/posts/compu…

SSH Port Forwarding: Why and How 🧵

If these problems sound familiar:

- A db server listens on a remote localhost, but you want to use a local GUI client
- A dev service runs on your laptop, but you want to expose it to the Internet

...and you don't know the solution, read on! 1. Simple Local Port Forwarding.

If you have SSH access to the target server, you can bind any port from this server to your local port.

Run the SSH client with the -L flag to make it listen on a local port. Any traffic to this port will be forwarded to the SSH server.

What Is a Distroless Container Image? 🧵

Go (programming language) is famous for its statically linked binaries. You can take a Go executable, drop it into a "FROM scratch" container, and call it a day.

But there might be a problem (keep reading) 👇 1. "FROM scratch" containers lack proper user management.

The "scratch" base image means an empty image. So, the `/etc/passwd` and `/etc/group` files are simply missing.

Most of the time, it makes the containerized process run as root.

Debunking Container Myths 🧵

A (never-ending) series of articles that I started writing a couple of years ago to fix my own misconceptions about containers 🔽 1. Does a container image have an OS Inside?

Turns out not! Read the article to see how to create a pure scratch container. And, more importantly, to understand why it's possible.

iximiuz.com/en/posts/not-e…