Containers

Open source contributions need not be great achievements. Actually, most of them are not, and that’s the way it’s supposed to be. In this paradigm, projects get better simply by being public and having people with different levels of expertise and involvement contribute to them. I recently contributed to a project that has allowed me to learn a good amount about networking. My contribution was eight lines of code. I admit that even if networking is something I already have some experience with and have been expanding my skills in recently, I don’t claim to be well versed in that specific project. Also, coming from a science background, I am fluent in Python and C++, and can understand, but not write much, Go (yet 😉). But I think that’s exactly the whole point of an open source contribution: we don’t need to be experts or hardcore programmers in the language a project is written in if we want to contribute. What we do need is the willingness to contribute, a problem to solve (or a feature to add), and the systems thinking needed to integrate it without breaking anything else (your PR won’t be merged otherwise anyway). This is even more true with the help of AI coding agents. ...

You docker run. You get containers with networking. It’s that simple. But is it? Under the hood, Docker creates network namespaces, virtual Ethernet devices, bridges, routing rules and everything else needed for containers to communicate. I’m following Drew Elliot’s Networking Course lessons; the first of which is mostly about how networking happens in containers. What follows is based on the notes I made during the course and revised on my own, including some concepts I wanted to revise. ...

Recently, I’ve learned about development in dev containers. This idea is great because it allows for siloed, reproducible, full-featured environments for development. Since DevOps is about enabling product work, dev containers are a great example of that. This idea can actually go further: dev containers can also be used for management, admin, and DevOps tasks, like Kubernetes cluster management. In that case, tools and configuration files are as important as application code. One can have a dedicated management environment for a single cluster, reducing the risk of accidentally targeting the wrong cluster. ...