As promised, another post (whoopie).

My blog has needed a bit of TLC for a while. Some of these are backend issues related to the build process and some of these are front end issues. The main one you will notice is that there is no longer an annoying $echo $LANG line at the bottom of every post. This was an artifact of the theme I’m using, fairly easily fixed by setting a site-specific version of the lang.html file. The RSS feed is still showing duplicate entries (one for the post, one for the PGP signature). I haven’t fixed it yet, but it’s on my radar (I fixed this shortly after publishing this post). What is most important however is that the site builds without error. So what does this mean? It means I can finally dip my toe into the wonderful world of DevOps. Yay?

Part 1: Building and Deploying with Jenkins

Basically the way I build my site currently is I post something to my blog-posts repo and then manually rebuild it using a python script. Once that is done I push it up to the GitHub repo which hosts my site. It’s all very manual, and for some time I have wanted to automate this process, so when I push something to the blog-posts repo it automatically builds and deploys. I also would like to take this a step further and make it so my site is no longer hosted using GitHub pages, and is instead hosted within my homelab itself.

So I spent today looking around for the best way to do this and this is how I imagine this is going to go

1) I push a post to the blog-posts repo - This originally was on GitHub, but has since been rehomed to my private Gitea service within my homelab. The reason for this is because my GitHub was always supposed to be a portfolio, and over time has slowly become just a dump for all projects I do which involve git, which is just about everything I do.

2) Gitea triggers a webhook - This is fairly simple, on push Gitea triggers a webhook to notify the CI/CD tool I’m going to use.

3) Jenkins builds site - Yes, I’m using Jenkins. Yes, I know it’s wildly overpowered for this. No, I don’t care. Upon receiving the webhook, Jenkins will clone the repo, run the Python script I wrote to extract signed markdown content and remove the inline PGP blocks, run hugo -t risotto to rebuild the static pages in the public repo, and then push the changes in public to my GitHub pages repo.

Sounds easy enough? I’m under no illusion that it actually will be. I have been tinkering with technology long enough to know I am being lulled into a false sense of security, and I am going to get a rude wakeup call. I look forward to it… Because I hate myself.

Part 2: GitOps & Argo CD

So I mentioned that I eventually want to host the site on bartmos-1, my homelab (specifically the rack). I will go into more details on this at a later date, most likely in the build-logs section of this site when I actually sit down and update it. I generally am trying to build my homelab out using IAC principles, and specifically using GitOps to do this. Given how my site is built and deployed (even now), it lends itself nicely to me being able to deploy my site on-prem using GitOps.

The workflow will change slightly. Steps 1–3 remain mostly the same, but now in step 3 Jenkins also updates a K3S manifest file.

4) Argo CD watches the deployment repo and redeploys- Given I eventually want to switch my docker hosts into a K3S cluster, and since Argo CD is a tried-and-tested way to implement GitOps with Kubernetes, it seemed like a natural fit. A lot of the tutorials I have seen that are to do with K3S clusters within a homelab also seem to use Argo CD, so it seemed like a good choice.

The reason why this is Phase 2 and not part of Phase 1 is simply because I just haven’t gotten around to setting up K3S yet. It has been something I have been planning to do since at least March, and whenever I think I am ready I discover a new tidbit of information that makes me reconsider what I am planning to do. For example, today I found out that using longhorn is probably not the best choice for distributed storage across the nodes given they will be done on LXC containers. I’ve also decided I should replace Uptime Kuma with a Grafana + Loki + Prometheus + InfluxDB stack first for monitoring should probably be done before I do my K3S build, just so that I have an actual monitoring solution in place when it happens. I’m also considering provisioning the LXC containers using Terraform instead of doing it all manually—but that’s a whole other rabbit hole.

This project hinges on a few other pieces falling into place before I can properly tackle it.

Overkill Goals

This did not need to be its own heading… I also want to eventually deploy my website to TOR and I2P also, but this is not something which I am even thinking about properly yet. I kind of know how to host something on TOR, I do not know the first thing about hosting something on I2P. You may question why I want to do this, and the answer is quite simple… I think it will be cool.

In actuality it is the case that I believe that tools like TOR and I2P are very important for the modern day. I also believe that if you don’t use something then you do not get to complain when you loose it. TOR alone is in danger of being corrupted almost constantly. I2P, while more secure, is frankly even more in danger simply because its limited userbase compared to its big brother. Also selfishly, I think it would look really cool on a CV that I host my site on those networks aswell as the clear net.

I’ll write more once I’ve got Jenkins doing what I want—or once it breaks everything and I regret all my life choices.