All articles

Saim Safdar from the Cloud Native Islamabad community generously invited me to his channel to conduct a Kubernetes 101 workshop. However, as often happens, I found myself pulled in a slightly different direction:

What if you don't start with Pods, Deployments, and Services and instead take a step back and look at how things were done in the past with good old VMs? Can it help you understand Kubernetes faster and deeper?

Below, I present a more polished version of the workshop, enriched with illustrations and runnable examples. You can experiment with these examples directly in your browser on labs.iximiuz.com.

Read more

The recent post by DHH regarding their decision to drop TypeScript support in Turbo 8 has suddenly made everyone eager to express their opinion on the TypeScript vs. JavaScript dilemma, and I'm no exception. Hell, I don't even know what Turbo 8 is, but I feel like I have something to share too. Just a few weeks ago I migrated one of my two biggest projects to TypeScript while keeping the other one using JavaScript, and this is exactly how I like it to be, for now.

Read more

Today, I came across a true gem: Akin's Laws of Spacecraft Design. Originally written for the aerospace engineering domain. I find many parts of it relevant for software engineers as well. Below, I share my thoughts on the Laws that resonate most with my experience as a software designer and tech blogger.

As it often happens, I discovered it through Matt Rickard's newsletter.

What DALL-E thinks the image for this blog post should look like.

Read more

This is a long overdue post on iximiuz Labs' internal kitchen. It'll cover why I decided to build my own learning-by-doing platform for DevOps, SRE, and Platform engineers, how I designed it, what technology stack chose, and how various components of the platform were implemented. It'll also touch on some of the trade-offs that I had to make along the way and highlight the most interesting parts of the platform's architecture. In the end, I'll, of course, share my thoughts on what's next on the roadmap. Sounds interesting? Then brace for a long read!

Read more

The only "official" way to publish a port in Docker is the -p|--publish flag of the docker run (or docker create) command. And it's probably for good that Docker doesn't allow you to expose ports on the fly easily. Published ports are part of the container's configuration, and the modern infrastructure is supposed to be fully declarative and reproducible. Thus, if Docker encouraged (any) modification of the container's configuration at runtime, it'd definitely worsen the general reproducibility of container setups.

But what if I really need to publish that port?

For instance, I periodically get into the following trouble: there is a containerized Java monster web service that takes (tens of) minutes to start up, and I'm supposed to develop/debug it. I launch a container and go grab some coffee. But when I'm back from the coffee break, I realize that I forgot to expose port 80 (or 443, or whatever) to my host system. And the browser is on the host...

There are two (quite old) StackOverflow answers (1, 2) suggesting a bunch of solutions:

• Restart the container exposing the port, potentially committing its modified filesystem in between. This is probably "the right way," but it sounds too slow and boring for me.
• Modify the container's config file manually and restart the whole Docker daemon for the changes to be picked up. This solution likely causes the container's restart too, so it's also too slow for me. But also, I doubt it's future-proof even though it's kept being suggested 9 years later.
• Access the port using the container's IP address like curl 172.17.0.3:80. This is a reasonable suggestion, but it works only when that container IP is routable from the place where you have your debugging tools. Docker Desktop (or Docker Engine running inside of a vagrant VM) makes it virtually useless.
• Add a DNAT iptables rule to map the container's socket to the host's. That's what Docker Engine itself would do had you asked it to publish the port in the first place. But are you an iptables expert? Because I'm not. And also, it has the same issue as the above piece of advice - the container's IP address has to be routable from the host system.
• Start another "proxy" container in the same network and publish its port instead - finally, a solution that sounds good to me ❤️‍🔥 Let's explore it.

Read more