Ivan on the Server Side


Hello friends!

Ivan's here with the June roundup of all things Linux, Containers, Kubernetes, and Server-Side craft ๐Ÿง™


What I was working on

The first two lessons (and a few challenges) of my "Alternative Introduction to Dagger" course have not sparked much interest among my students, so I had to put this work on pause. With a heavy heart, though, because I do like Dagger, and I was enjoying working on the content about it. But no interest means fewer iximiuz Labs Premium subscribers, and I don't want to ruin the nice uptrend that has been forming since the beginning of the year ๐Ÿš€

What's next? Back to the roots!

I've been tech blogging for the past 5 years, and I've got a ton of materials on containers in general and Docker in particular. However, the problem with my blog has always been a lack of structure โ€” if someone wanted to learn containers from "zero to hero" using only my blog, it'd be virtually impossible. One can learn a thing or two from a number of quality deep reads, but there is no clear learning path.

Another vital but often overlooked aspect of learning a new technology is building "muscle memory" - it's impossible to learn Docker by only reading about it. However, running just one container is not enough either. You have to create, start, stop, and destroy a dozen containers in different scenarios before the corresponding skill forms.

Last but not least, the right dosage is the key to sustaining motivation over a long time. My new mantra is less dry theory, more visuals, and practical tasks.

Luckily, the "expression means" of iximiuz Labs should help me fulfill all three requirements! So, in June, I started working on the course with a working title:

Bite-Sized Docker: Mastering Containers The Hands-On Way

Not sharing the link just yet, but here are some useful on their own by-products of this work:

The fact that the first challenge in the above list is the most popular piece on the platform makes me think this course should generate much more interest ๐Ÿ’ช

Traditionally, you can support the course development by getting iximiuz Labs Premium.

Get more powerful playgrounds, unlimited egress traffic, and full content access with iximiuz Labs Premium. Does your company have a learning and development budget? Then this expense most likely can be reimbursed.

What I was reading

โ€‹VpK - Visually presented Kubernetes (GitHub) - An interesting project that can do truly impressive visualizations of Kubernetes clusters. Visualizations look definitely more advanced than kexp's (by yours truly). But unlike kexp, which tries to convey the dynamics of the object graph, VkP works only with fixed snapshots of the cluster state. So these tools aren't mutually exclusive.

โ€‹Simplifying Kubernetes Development: Your Go-To Tools Guide - A concise and handy overview of the mainstream Kubernetes development tools: Skaffold, Tilt, Telepresence, Okteto, Docker Compose (?), and Garden. All but Garden have been on my radar for a long time (but I havenโ€™t spent much time with any one of them, so canโ€™t share my experience yet).

โ€‹Simon Willisonโ€™s Weblog - One of the best โ€œold schoolโ€ tech blogs that is still active! Currently covered topics are quite relevant, too - including BS-free LLM content. Do recommend!

โ€‹Malicious VSCode extensions with millions of installs discovered - Kind reminder: in 2024, installing development tools to your precious laptop should be considered harmful! My personal recommendation is ephemeral & disposable remote dev environments. Iโ€™m a heavy user of my own labs.iximiuz.com for all things experimentation, including checking out non-trusted GitHub projects. And when it comes to development, I provision slightly longer-running but still fully isolated and disposable VMs (or bare-metals) - one per group of related projects (e.g., work vs. personal).


Wrapping up

June has been the most fruitful month for positive feedback so far. There is a person who solved every single challenge and finished every tutorial and every course on the platform (truly impressive!), a number of folks who shared the link to the labs with their managers and/or CTO as their go-to resource for learning containers, and even a couple of leads from well-known companies considering iximiuz Labs for hosting their edu content. This is all mind-blowing and reassuring! To the new peaks in July ๐Ÿš€

Have a great month ahead!

Cheers

Ivan

P.S. A huge thanks to everyone who replied to the previous email! Thanks to your efforts, the domain reputation is back to high, and the delivery rate seems fully recovered.

Ivan Velichko

Building labs.iximiuz.com - a place to help you learn Containers and Kubernetes the fun way ๐Ÿš€

Read more from Ivan Velichko

Hello friends! Ivan's here with another monthly roundup of all things Linux, Containers, Kubernetes, and Server Side ๐Ÿง™ The issue's main topic is iximiuz Labs' largest-ever upgrade: Fresher and more streamlined look of the frontend UI ๐Ÿ’™ A new 5.10 Linux kernel built with nftables support (finally, we can try out kube-proxy's nftables mode). New default playground user - laborant (yep, rootless containers learning for). New playgrounds: Ubuntu 24.04, Debian Trixie, Fedora, and Incus (yay! more...

Hello friends! Ivan's here with a slightly delayed July roundup of all things Linux, Containers, Kubernetes, and Server Side ๐Ÿง™ What I was working on This month, I got nerd-sniped by cgroups. It all started when I ran into a pretty significant difference in how Docker and Kubernetes handle the OOM events. When you limit the memory usage of a multi-process Docker container, the OOM killer often terminates only one of the processes if the container runs out of memory. If this process is not the...

Hey there ๐Ÿ‘‹ I spent a few weeks deep diving into cgroup v2, and I'm happy to share my findings with you! Everyone knows that Docker and Kubernetes use cgroups to limit the resources of containers and Pods. But did you know that it's very easy to run an arbitrary Linux process in a cgroup using much more basic tools? The only kernel's interface for cgroups is the virtual filesystem called cgroupfs typically mounted at /sys/fs/cgroup. Creating folders there and writing to files in them is...