k8s / blog update
This commit is contained in:
parent
ab3b70f718
commit
559c0c45c4
1 changed files with 20 additions and 17 deletions
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue