Cloud

A while ago, there as a little bit of a conversation happening on Twitter, that was sparked by Matthias’s statement that more and more meetups are happening again. Now only a short year later, I felt like it was time. The time to actually follow through and start a new conference. In case you haven’t seen it yet:

SkySummit

This is a new thing. I mean, sure, I’ve organised a handful of concerts when I was in my early 20s, but I’m not sure that’s comparable. So I thought, I’d share my learnings here in a blog post, or rather series of them, since the whole thing is still ongoing. I want to somehow share the experience but also maybe help others to know what they’ll need to get their own conference started.

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”.

Before you dive deep: This will not give you a working local OpenShift on Apple Silicon but a working CRC using Podman.

At the very end of my last post I briefly mentioned that CodeReady Containers(CRC) were not available for Apple Silicon. Literally two hours later I came across a GitHub Issue that’s functions as an epic ticket for CRC support on M1 and guess what? There’s a new comment hinting to a dev preview version. Naturally, I installed went and tried it and here’s how it went.

After receiving my new M1 powered MacBooks Pro I was happy. Very happy. After all, it was quite the upgrade from the shabby Intel I5 powered MacBook Pro that I was running while still working at Red Hat. Everything is so blazing fast now, and it just feels nice. While I was aware that not all CLI tools have yet been cross-compiled for ARM, I had a tiny “what the fuk” moment when I wanted to get the work on the “Operating OpenShift” book going and found out that basically none of the tooling was ready for Apple Silicon. As you can imagine, not being able to use any of the CLI tooling isn’t really great to write a book about OpenShift. In essence, I couldn’t create clusters or use the oc CLI to interact with any clusters.

As the title is hinting, this is part one of a series of entries to follow. This first post will deal with a topic that I personally have to touch on a lot: Deploying to Cloud Run. Why? This very blog you’re reading right now is deployed precisely that way. In this article, we’re going to walk through a couple of simple steps to get a hugo based blog (or anything more or less) deployed to Google Cloud Run using GitHub Actions.