Docker

It’s been years and years since Jessie Frazelle actually gave a phenomenal talk about Container Hacks and Fun Images. Basically this talk actually got me into containers back then so shout-out to Jessie for that. However, it’s been long 9 years, tools have changed, docker changed and I feel like it’s about time to give it a shot again, to try to stick everything in a container that’s needed for day to day work. Basically, we’ll build our own Silverblue. I’ll bring you along on the ride again (as per usual), so this is not going to be a pitch perfect guide, but rather we’ll be building those images and commands together.

This one will be a little shorter, but still something worth talking about: how to set up the repo. I know, I know: “Just click the button”. That’s not really what I mean. It is more about everything I like to have in repo.

Community standards

License

The license topic has gotten pretty hot recently with a bunch of OSS projects moving to very interesting forms of licensing be it SSPL like Elastic and MongoDB haven chosen to or AGPL like Grafana. None of these are relevant for what we are doing here right now, and they’re also having their own caveats which are caused by their purpose: protect the main contributor companies. I’ll not spark a discussion on this topic, the fact is, we want to use a significantly more open license: Apache 2.0. As for all things there is a great website explaining the importance of licenses and the implications. What matters for us is really the community acceptance but also what it has to offer. The tl;dr is that you can do whatever you want with the code, we’re not liable for that, and you can’t use the “pleaco” trademark (which we don’t have at this point). You can find more choices for licenses here as well as the whole License print.

Time to get going. First things first: we need to create a repository and initialize it. GitHub is the easy choice here, but also just as good as any other option right now. We follow the documentation to create ourselves a nice organisation so just in case this is actually going to be cool, the whole thing doesn’t just live in my personal space. Really, when you consider making something cool that might have an open source community in the future, keep it out of your personal space. It’s easy, it’s free, and it will save you a lot of pain in the future.

After spending a lot of time on Stack Overflow recently, a thought started pestering my brain: why is Kubernetes so complicated? This was followed by “Can I build something simpler?”, and so here we are, building our own Container Platform from scratch. Platform engineering is super hot right now so let’s have our own go at it. At the end of the whole thing, you will find the whole result oin GitHub, Open Source of course.

Recently I’ve been trying to answer some more questions on stack overflow. For one to be a better member of the community but on the other hand also because I’ve been somewhat interested in joining the Docker Captain’s program and there are some requirements around activity, but that’s a story for a different day. Anyhow, after a lot of more or less simple questions, I landed at a super cool one. The title wasn’t instantly giving away how deep of a rabbit hole I was about to explore: “Minikube to deploy linux/amd64 images on M1 hardware”.