From 559c0c45c476eff810c8b254e91fd471bdc98df7 Mon Sep 17 00:00:00 2001 From: Nico Schottelius Date: Sat, 12 Oct 2024 00:47:59 +0900 Subject: [PATCH] k8s / blog update --- blog/2024-10-11-moving-into-k8s.mdwn | 37 +++++++++++++++------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/blog/2024-10-11-moving-into-k8s.mdwn b/blog/2024-10-11-moving-into-k8s.mdwn index 52764e82..574fc1f4 100644 --- a/blog/2024-10-11-moving-into-k8s.mdwn +++ b/blog/2024-10-11-moving-into-k8s.mdwn @@ -2,14 +2,14 @@ ## History -I started this website in 2008, according to the -[git log on the -2008-10-30](https://code.ungleich.ch/nico/www.nico.schottelius.org). Since -then it has been based on [ikiwiki](https://ikiwiki.info), a sample +According to the [git +log](https://code.ungleich.ch/nico/www.nico.schottelius.org) I started +this website in 2008. Since +then it has been based on [ikiwiki](https://ikiwiki.info), a simple word processor. This website has been hosted on many different physical and virtual -servers since then. And now... +servers since then. And now it is ... ## Moving into kubernetes @@ -28,8 +28,8 @@ focus on sustainability. The infrastructure at ungleich has been always evolving and one of the earliest credos was to run anything that is potentially being offered as a product ourselves. Thus any service you can get from ungleich, is also being run internally - -anything from Matrix to Nextcloud to Mattermost to Netbox, you name -it. +anything from Matrix to Nextcloud to Mattermost to Mastodon +to Netbox ..., you name it. ## VM workloads are getting old @@ -43,19 +43,22 @@ kubernetes for ungleich is to be able to run many similar services While we are still using [cdist](http://cdi.st/) for configuration management and for configuring servers (both bare metal as well as VMs), deploying applications via kubernetes is now a well known -pattern and effectively reduces the effort. +pattern and effectively reduces the effort for maintenance, as many +apps can be updated with one git commit. -This particular website is running on a virtual machine we internally -call "staticweb", as it only hosts statically generated websites, no -dynamic content at all. +This particular website was running on a virtual machine we internally +call "staticweb", as it only hosts statically generated websites, +without any dynamic content at all. -And it has been on our "to migrate" list for about 1.5 years. So it's +And that VM has been on our "to migrate" list for about 1.5 years. So it's time to move on... ## How to run a website in kubernetes -There are so many different ways to run applications in kubernetes, -today I want to show you a rather simple one. As I mentioned, this +There are so many different ways to run applications in kubernetes and +a lot depends on your environment and your workflos. + +Today I want to show you a rather simple approach. As I mentioned, this website is built using ikiwiki and backed by git. It actually uses a [Makefile](/Makefile) for a long time and since today also a [Dockerfile](/Dockerfile) to generate its own container. @@ -68,7 +71,7 @@ essentially to: * upload the container * update the argocd manifest to refer to the latest container -And each step is only executed if the previous one was successful. +And each step is executed only if the previous one was successful. Instead of using a too fancy build pipeline that runs async in some amazing build cluster I am just executing @@ -88,8 +91,8 @@ is that there can be a lot of cruft. As we are using an internal [harbor](https://goharbor.io/) instance that runs IPv6 only to host our images, at some point the storage would run out if ... we did not specifiy a policy for automatic image deletion. In case of this -website, the last 5 images are kept and when more exists, on a weeky -basis pruned. +website, harbor checks once per week whether there are more than 5 +images and if so, removes them. One drawback of the current build is that the ikiwiki run takes about 2 minutes and depending on my connection the image push might also