Ivan Velichko Profile picture
Aug 28 8 tweets 3 min read
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.

2. You Don't Need an Image To Run a Container

The workflow popularized by Docker might make you think that images are rather mandatory to run containers. Well, they are not. But what are they for?

Read the article to learn the truth 😉

3. You Need Containers To Build Images

Continuing the theme of how images is the secondary construct - read how Docker (used to) build images.

*things might've become more involved with buildx, but this article remains a good starting point.

4. Containers Aren't Linux Processes

Not every container out there is built of namespaces and cgroups. But even when it's a traditional Linux container, it's not really a process. What is it then?

Read the article to find out 😉

5. From Docker Container to a Linux VM

A (not only thought) experiment to show how thin is the line between containers and full-fledged virtual machines.

Might help you to break a few mental barriers on the way to a better understanding of containers 😉

There are more articles available on the blog, and a few new write-ups are coming out soon.

The best way not to miss them? Subscribe to my monthly round-up 😉

All 29 (and counting) articles on Containers 👇


• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Ivan Velichko

Ivan Velichko Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @iximiuz

Aug 20
Linux vs GNU/Linux vs Alpine Linux 🧵

1. Linux is the kernel. What Linus wrote in the 90th. That's it.

Interesting fact: Excluding drivers, the kernel itself is just a few megabytes when compiled.
2. GNU is a large collection of free software which can be used as an operating system (or in parts with other operating systems).

You, of course, know this software very well: grep, sed, gcc, the list goes on.

GNU includes the C standard library implementation called glibc 🔥
3. GNU/Linux is any Linux distro (kernel + userland) based on the GNU collection.

Debian, Ubuntu, CentOS, and even RHEL are technically GNU/Linux.

Because of the common C stdlib and system tools, often you can jump between GNU/Linux distros w/o much trouble ❤️‍🔥
Read 5 tweets
Jul 27
How knowing Container Fundamentals helps you use Kubernetes more efficiently 🧵

Here is an example:

To facilitate freeing production images from unnecessary tools Kubernetes introduced Ephemeral Containers and the new `kubectl debug` command.
Now you can start an interactive shell in the misbehaving Pod using your favorite debugging toolkit image:

kubectl debug -it --image <IMAGE> <POD>

This allows to keep prod images slim without sacrificing the troubleshooting effectiveness. But there is an issue 👇
The `kubectl debug` command launches a totally new (ephemeral) container in the target Pod.

But even within a Pod, there are borders between containers.

By default, you won't see:

- Other Pod's processes
- Other containers' file systems

Luckily, there are some workarounds 👇
Read 7 tweets
Jul 24
Kubernetes basics explained by analogy 🧵

...or "How Kubernetes Just Repeats Good Old Deployment Patterns"

1. For a long time, people had been deploying services as groups of virtual (or physical) machines.

But VMs were often slow and bulky. Hence, not very efficient.
2. Then containers gained quite some popularity.

With containers, it became easier to distribute services. Reproducibility also improved. But containers haven't become a replacement for VMs.

Mainly, because of their deliberate focus on being an environment to run a single app:
3. Instead of containers, another abstraction took off - Kubernetes Pods!

A Pod is a group of semi-fused containers. External borders were preserved, but some of the internal isolation b/w containers substituting a Pod got weakened.

A Pod is a much closer abstraction to a VM.
Read 8 tweets
Jul 22
How could I miss Async Hooks arrival in Node.js!

Me in 2014, using Python: Thread-local storage for ctx propagation is awesome!

Me in 2017, switching to Node.js: Can I have seamless ctx propagation, pleeease!

Me in 2019, using mainly Go: Explicit ctx passing! This is the way!
For the context (no pun intended), I've been reading the OpenTelemetry JS SDK code lately, and couldn't understand how this may work:

import { context, trace } from 'opentelemetry/api'

function async myHandler() {
const span = trace.getSpan(context․active())
Since the async `myHandler` function can be called concurrently from multiple request handlers, the `active` context cannot be not shared. Or so thought I...

But then I learned about the AsyncHooksContextManager module 👇

Read 6 tweets
Jul 19
Why AWS Lambda is great for pure FaaS and poor for generic HTTP workloads (thread) 🔽

As always, my take. YMMV.

1/ Lambdas are just great as ad-hoc tiny little handlers for:

- Stream events: CloudWatch/Kinesis/DynamoDB
- Queue messages: SNS/SQS
- Simple webhooks: API Gateway
2/ Why AWS Lambda excels in the above scenarios:

- Easy to deploy: you can just submit a piece of code
- Easy to monitor: you're generally interested in the absolute invocation duration and the binary outcome (ok/ko).
- Easy to scale 🫰
- And no servers! 🔥
3/ Everything changes when you start using AWS Lambda for full-blown HTTP services:

- Deployment slows down (it'd in any case but it cancels out one of the former pros)
- Observability isn't on par with ECS/EKS
- Scaling up becomes expensive
- What's up with blue/green & canary?
Read 9 tweets
May 29
Kubernetes Ephemeral Containers 101

Slim production images is a must - they are fast(er) and secure(r). But there is a problem - they lack debugging tools.

Ephemeral Containers and the `kubectl debug` command help you make the debugging tools available in the cluster on-demand.
The simplest way to start an ephemeral container in an already running Pod:

kubectl debug -it --image busybox <POD>

The command:
- Updates the Pod spec.
- Starts a new busybox container.
- Attaches your terminal to it.

Without disrupting the Pod!
But there is a problem with the `kubectl debug` default behavior.

You need this command to debug containers in a Pod. However, by default, you won't even see their processes. Nor you'd have access to their filesystems.

Solution 1: Enable shared process namespace on the workload
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!


0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy


3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!