While I’m no stranger to building dashboards, there was always something that bothered me when I was using Grafana for displaying the metrics I wanted to look at: it was a web app! Now, while web apps are much maligned, they do serve a purpose. But for the purpose of displaying rather the rather simple information that Prometheus collect (yes, simple: a complex metric is a useless metric IMO), a web app seems overkill. And now that TUIs are back en vogue, I thought it could be a fun exercise to build a TUI for displaying Prometheus metrics. Hence, gopromtui: a lightweight, terminal-native solution for displaying Prometheus metrics without any additional infrastructure.

After finishing my previous project, I felt an itch to continue building. One of the things that was noticeable during that process was that my coding skills were not being pushed: while the app I built did teach me about integration of Prometheus inside a Golang application, there wasn’t much else new for me there. So, for my next project, I chose to concentrate on building software.

The question then became: what should I build? It occurred to me that if I wanted to concentrate on improving my software development skills, that I should choose a domain that I have some experience in, so as to remove an extra layer of complexity for the project. As I have some experience already with Kubernetes, and given that I love CLIs, the union of those two things seemed like a natural choice. I even already had a cluster running that I could easily test things on!

Part 1

This is going to be a series of posts about a learning journey on what it takes to build a GitOps pipeline, with the added constraint that I’m going to be self-hosting all of the necessary parts to achieve this. On one hand, it’s bound to be a great exercise to put together disjointed pieces of knowledge I already had; and on the other, it serves as a way to document the journey for people that might be interested in knowing how such a thing is possible.