ungleich-public/ungleich-staticcms
6
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

add blog about moving staticcms to k8s

Browse source
This commit is contained in:
Nico Schottelius 2024-10-13 12:23:24 +09:00
parent 3fe3805d4a
commit 7ad4747a08
1 changed files with 109 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

109
content/u/blog/2024-10-13-staticcms-moved-to-kubernetes/contents.lr Normal file
View file

@ -0,0 +1,109 @@
title: Our staticcms has been moved to kubernetes!
---
pub_date: 2024-10-13
---
author: ungleich web team
---
twitter_handle: ungleich
---
_hidden: no
---
_discoverable: yes
---
abstract:
One more service in k8s
---
body:
## Moved to kubernetes
This website and all static content has been moved to Kubernetes as of
2024-10-13. The motivation and background is very similar to what
[Nico wrote on his
blog](https://www.nico.schottelius.org/blog/2024-10-11-moving-into-k8s/)
already some days ago.
## Build system for teams
Differently to what Nico is doing with his private homepage, this
website will be moved into a "fancy build" system. The background is
that while for a single person running `make` on the laptop which
modifies argocd cluster configurations, for a team of people working
on the website, things are a bit more difficult.
For once, not every computer at ungleich is running Linux, we do have
some non-Linux machines and also machines not run by our kubernetes
team, so there is no direct argocd access. And neither is docker build
available on some machines.
How the build pipeline will look exactly is still to be defined, but
once we have settled on one, you will link the details here - so stay
tuned for updates.
## Static websites pattern
One thing we would like to share is already the structure of the helm
chart we are using for deployment: We have one helm chart that uses a
list of containers that should be deployed. Deployed by argocd
it essentially looks like this:
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: staticweb-nico
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
destination:
namespace: nico
server: 'https://kubernetes.default.svc'
source:
path: apps/prod/staticweb
repoURL: '...'
helm:
valuesObject:
websites:
- name: www-nico
image:
harbor.k8s.ungleich.ch/nico/www.nico.schottelius.org:559c0c45
fqdn: www.nico.schottelius.org
project: default
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
```
The name attribute is used for defining the k8s `Deployment`, the fqdn
is passed to the nginx-ingress and the image should be pretty clear.
You may notice that we use our own image registry based on
harbor. Not only is this much faster for pulling images, but it also
solves problems with other registries:
* github (ghrc.io) is legacy IP only and cannot be used from the
Internet
* docker hub has very strict pull limits, often not allowing us to
pull in images. While this can be worked around with using a login
token, it add a certain complexity to our infrastructure deploying
logins for various registries.
This brings us to something some of you might have noticed already:
## Our containers are publicly reachable
Anyone can download any container hosted on our harbor instance
without authentication. This is by design, as containers should only
contain public data. All our containers contain public, open source
applications only.
Data is being injected either by an sqldump in the beginning (if it is
an existing application) or generated at startup or passed in as a
secret independently of the container.
From our perspective this principle allows easy and strict separation
of private vs. public data.