Around 3 years after my last post it is funny how I have to re-reclaim my installation. Time is a big threat to software systems, and every veteran software developer or general IT worker can assure you that most enterprise systems are old, will stay old, and just need to be maintained and sometimes even reclaimed. Of course you can work on slowly modernizing everything. There are patterns on how to achieve this goal like going microservice architecture, facading certain parts with new frontends, well … many more. This post is not about how to modernize old software, this is about the fact that you will always have to reclaim certain things, deal with time that just passed on systems that you did not touch for a long time, and then have to update and modernize things that just need to work without you wanting to do all necessary changes that come with updates.
Also it is important to understand, that the longer you are away from a project, the more things you have forgotten. What are requirements of the project on my system? How do I build it, run it, test it, get quick feedback? Getting quickly back into a system can be tricky especially if there is not much or any documentation, open ends that were marked as a TODO, a maybe later, or whatnot.
These things happen. As much in professional environments, even more in private settings where stakes are low, time is scarce and quality not the primary concern.
What to do first
Well clearly this page was up all the time since the last post. It is in fact just a statically created HTML page without much stuff. So of course nothing much will happen in time. But the system to create this page did age again. Luckily I reclaimed it properly with docker, so re-reclaiming should not be that much of a problem at this point.
So the bigger problem is the lost knowledge that just vanished in this time. How to work with the system, how do I deploy, how do I do all the things that need to be done.
And of course, these things cascade. Not only did I not touch the blog for a long time, I also did not have time to update / upgrade / maintain my gitea server. So login needs to be reclaimed aswell. Also it desperately needs updating. And in this specific case, apparently I did not even commit the reclaiming properly, because there were things to be done before that, which, as it is, were never done, or left in a half state.
This is the reality of things. Denying them, claiming to always be perfect, or just hiding them in this very blog, would help no one. I do have high quality standards. And that’s why I am good in my job and do proper work there. That’s why my private life works well too. But as focus is elsewhere, there are aspects that wither along. This is apparently one of them.
Revisiting things
But with every downside there is new opportunity. Apparently back then the best decision was to host my own git server. I remember that it was gitosis before, and I switched it to gitea, which was the best option back then. Nowadays with GitHub having been acquired by Microsoft, and them changing their free plans, the best option for the future currently looks like switching to GitHub. With that I do not need to worry about outdating my base, and I have it still somewhere safe. Of course switching repositories again, moving them over, reclaiming things is a tedious task. But that way I could decommission my old gitea installation and have one less thing to worry about.
So that’s the plan for the future. For now, let’s still focus mainly on the blog, and how to move forward.
Necessities
The minimum things that need to be done is hosting of the repository, a quick way to develop and test, and a quick way to deploy.
Hosting of the Repository
This should be easy. Just move the repository to GitHub.
First we create a private repository in the web frontend. No templates, no created readme file. Just a naked repository.
Now we can utilize the given cheatsheet in GitHub to commit to this repository. This part was easy, just that we could not simply copy-paste as we already did have a origin. But origin2 was free, so I went with that.
Quick develop and test
In order to do that we go my standard route of providing a Makefile. Interestingly enough there is an uncommitted Makefile lying around in my code.
It does have a make default that points to the documentation, and showing all targets. It also has targets for test, build and deploy. Although they all just echo a simple TODO. Well, I did have good intentions.
The test one is easy. As I was using the docker-entrypoint.sh pattern (which I just made up myself, I don’t really know if it is called that, but it is a pattern), I did prepare certain tasks like install, build, bash and start. Seeing as start creates a server for localhost for quick testing that is exactly what I want my make test to do.
test: ## Runs the local test server on localhost:4000
docker-compose upQuick way to deploy
Now on to building and deploying. With having a half eye watching Kamal I want a docker image that holds and hosts the blog. This should be based on nginx. So I quickly whip up a dockerfile for the serving part of the homepage for now, but will not implement it just yet, as a proper deployment pipeline with kamal needs some preparations like a docker registry, secret management, and setting up a GitHub Action to do all that.
FROM nginx
COPY _site /usr/share/nginx/htmlThe proper way is to create a complete container that just needs to be started that will serve the homepage. That’s what I am doing here.
The plan then is to just serve the container through Kamal to my box. But as that is future speak, I need a quick way to at least manually deploy the current site to my current setup. So let’s just make a quick and simple scp command straight to the server for now, leaving the work for the future (or to be reclaimed once again).
Now finally, as you can see this blog post as proof, all this re-reclaiming worked once again. But this time, I do have one or two more posts that I am working on. Crossing fingers.