Meetup.mu was a weekend project for me. It then became a lot bigger as people saw its importance. Sooo, in the end, this became my first project to get contributors who are not me, myself, or I. When I was developing locally, it was really easy to run a quick command I had saved: docker build . -t meetup:1.0 && docker push meetup:1.0 . But when I got contributors who opened PRs, the process got more complicated.
I had to first merge the PR. Then pull the new version to my machine. Afterwards, run the command above. Followed by changing the version in the Kubernetes manifest. And handing off the update to ArgoCD while I go to sleep. The latter because tech people insist on submitting PRs at awful hours of the night. Without ArgoCD, I would have more work, including ssh-ing to my K3S cluster and restarting the deployment to re-fetch the image.
So, simply put, I wanted to automate the whole process.
ArgoCD
ArgoCD is my first line of automation and to manage my whole cluster. All manifests are in a public repo, which Argo pulls from to set the state of the deployments. It ensures that all my changes and manifests are primarily in a Git repo so I can fail-over to a second cluster in less than an hour if I need.
ArgoCD can check for updates to the manifests and stage the update if necessary. It also gives me a handy UI to see the state of all my applications and the different pods and other K8S objects. Overall, a really useful tool, and my first install in any new Kubernetes cluster.
Version Incrementing
So, I had to change the version in the Kubernetes manifest every time a new version is out. I also had to change the version in the Docker build/push process. So basically, I had to use my brain. Why should I use my brain if my computer can do it for me?
I wrote a "simple" Python script which retrieves the version from a version.txt file. It then increments either the major or minor version number, and rewrites it to the file. Then, it uses Jinja with a template of the deployment, fills in the new version, and writes it to the deployment.yaml file, which ArgoCD picks up on later down the line.
Then there's a Makefile which lets you do make major or make minor to increment the major and minor version numbers automatically. I leave this up to the programmer, as maybe you don't want a push to main to lead to a redeployment. Well, maybe that's why you have branches. Oh well...
Docker Build/Push
The simplest solution I here is to get Github to build and push the image for me. A simple GH Action was all I needed, which logs in to my personal registry, retrieves the version from the version.txt file, then builds and pushes the image.
It was my first time playing around with GH Actions, so I'm pretty pleased that it runs fine and completes the last piece of my CI/CD cycle.
Next Steps
So I think next I have to figure out how to increment the version and essentially send the new versions back to main without starting the action all over again in a never-ending loop.
In the meantime, the Python solution works quite well, though I am tempted to rewrite it in Rust to then have a binary anyone can run anywhere.