Our staticcms has been moved to kubernetes!

Posted on 2024-10-13 by ungleich web team

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 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.