Updates

Gibt es eine neue Version, sehen Administratoren unter Einstellungen neben Lizenz den Hinweis Update und bekommen eine E-Mail mit dem, was sie bringt. Was jede Version gebracht hat, steht im Änderungsprotokoll.

Welche Version läuft

Die Images gibt es unter mehreren Namen:

Für eine Installation, die sich selbst aktualisiert, ist stable richtig (mit Watchtower oder Keel) oder ein Versionsbereich (mit Flux); für eine, die Sie von Hand aktualisieren, eine feste Version.

Von Hand

Mit Docker Compose setzen Sie DDM_VERSION in .env und starten neu:

docker compose pull
docker compose up -d

Mit Kubernetes ändern Sie die Version in ddm.yaml und wenden die Datei wieder an (kubectl -n ddm apply -f ddm.yaml). Hat sich ddm.yaml auf der Seite Kubernetes seit Ihrer Version geändert, übernehmen Sie das dabei.

Das CMS sichert die Datenbank und spielt die Migrationen ein, bevor es Anfragen annimmt. Mit Docker Compose starten Render-Worker und Leser-App erst danach.

Neue Installationsdateien

compose.yaml und ddm.yaml tragen ihre Version (DDM_DEPLOY_VERSION). Meist läuft eine neue DDM-Version mit den Dateien, die Sie haben. Für die beiden Fälle, in denen nicht, gilt:

• Fehlerbehebungen (0.26.1 → 0.26.2) brauchen nie neue Dateien. Folgt Ihre Installation 0.26 oder mit Flux 0.26.x, passen ihre Dateien immer.
• Eine neue Version (0.26 → 0.27) kann neue Dateien brauchen. Dann steht unter Einstellungen › Lizenz und in der E-Mail zur neuen Version: „braucht neue Installationsdateien". Übernehmen Sie in dem Fall vor dem Update compose.yaml oder ddm.yaml aus diesem Handbuch – Ihre Einstellungen in .env beziehungsweise config.env und secrets.env behalten Sie – und aktualisieren Sie dann.

Läuft eine Installation mit Dateien, die älter sind, als ihre Version braucht – etwa weil sie mit stable von selbst aktualisiert hat –, sehen ihre Administratoren unter Einstellungen neben Lizenz den Hinweis Prüfen und dort, was zu tun ist; das CMS schreibt es auch in sein Log.

Unterstützte Versionen

Wir unterstützen die Versionen ab einer, die wir Ihrer Installation mit jeder Lizenzerneuerung nennen. Läuft sie mit einer älteren, sehen die Administratoren Prüfen neben Lizenz und bekommen einmal eine E-Mail. Die Installation läuft weiter – aber Fehlerbehebungen, auch für die Sicherheit, gibt es nur für neuere Versionen.

Automatisch mit Docker Compose

Setzen Sie DDM_VERSION=stable in .env. Watchtower mit --label-enable aktualisiert dann die Dienste mit dem Label com.centurylinklabs.watchtower.enable – CMS, Render-Worker und Leser-App, nicht Postgres –, sobald wir eine Version freigeben:

docker run -d --name watchtower --restart unless-stopped \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.docker/config.json:/config.json:ro \
  containrrr/watchtower --label-enable --schedule "0 0 3 * * *"

Automatisch mit Kubernetes

Zwei Werkzeuge kommen in Frage. Sie arbeiten verschieden:

Postgres aktualisiert keines der beiden: Sein Tag 18 ändert sich nur mit einer neuen Hauptversion, die eine Umstellung der Daten braucht.

Während eines Updates startet das CMS neu und spielt die Migrationen ein; DDM ist dann ein, zwei Minuten nicht erreichbar.

Keel

Keel prüft in festen Abständen, ob es unter dem Tag stable ein neues Image gibt, und startet die App damit neu. Es nutzt dafür das Registry-Secret ddm-registry der Deployments.

1. Keel installieren:

   helm repo add keel https://charts.keel.sh
   helm repo update
   helm upgrade --install keel keel/keel --namespace keel --create-namespace
   

2. stable eintragen: In ddm.yaml bei cms, render-worker und client statt der Version den Tag stable – …/cms:stable und so weiter – und anwenden:

   kubectl -n ddm apply -f ddm.yaml
   

3. Die drei Apps an Keel geben:

   kubectl -n ddm annotate deployment cms render-worker client --overwrite \
     keel.sh/policy=force \
     keel.sh/match-tag=true \
     keel.sh/trigger=poll \
     keel.sh/pollSchedule="@every 6h"
   

   
   force mit match-tag heißt: derselbe Tag, neues Image – genau das, was beim Freigeben einer Version unter stable passiert. Alle sechs Stunden schaut Keel nach.

Ab dann aktualisiert sich die Installation selbst. Ob Keel etwas gefunden hat, zeigt kubectl -n keel logs deploy/keel.

Flux

Die Image-Automatisierung von Flux liest die Versionen in unserer Registry, schreibt die neueste passende in ddm.yaml in Ihrem Git-Repository und spielt sie von dort ein. Sie folgt einem Versionsbereich, nicht dem Tag stable – am sichersten den Fehlerbehebungen Ihrer Version (0.26.x); die nächste Version (0.27) stellen Sie dann von Hand um.

Vorausgesetzt ist ein Cluster, den Flux aus einem Git-Repository betreibt, mit den beiden Image-Controllern – bei einem neuen Cluster:

flux bootstrap gitlab --owner=<Gruppe> --repository=<Repository> --path=clusters/production \
  --components-extra=image-reflector-controller,image-automation-controller

1. ddm.yaml ins Repository legen, zum Beispiel unter clusters/production/ddm/, mit einer genauen Version (…/cms:0.26.1). Die Vermerke, wo Flux eine neue Version einträgt – # {"$imagepolicy": …} hinter den drei Image-Zeilen –, stehen schon darin.
2. Flux die Registry lesen lassen – mit demselben Deploy-Token, als Secret im Namespace flux-system:

   kubectl -n flux-system create secret docker-registry ddm-registry \
     --docker-server=registry.gitlab.com \
     --docker-username=<Name des Tokens> --docker-password=<Token>
   

3. Was Flux beobachtet und wohin es schreibt: ddm-updates.yaml, unten, ins selbe Verzeichnis. Setzen Sie darin range (dreimal), path und die E-Mail-Adresse der Commits.
4. Committen und pushen. Flux prüft stündlich; jede neue 0.26.x landet als Commit in Ihrem Repository und im Cluster. Für die nächste Version setzen Sie range auf 0.27.x (dreimal) und die drei Versionen in ddm.yaml von Hand.

# Updates by Flux's image automation, for an installation Flux runs from a
# Git repository (user guide, „Updates"): beside `ddm.yaml`, in the folder
# Flux applies. It reads our registry every hour and writes the newest
# version in `range` into `ddm.yaml` — behind the `$imagepolicy` comments —
# commits and pushes it.
#
# Set before committing:
#   - `range`, three times: your version's fixes, e.g. `0.26.x`;
#   - `path`: the folder `ddm.yaml` is in, from the repository's root;
#   - the commit's `email`, and `branch` if yours is not `main`.
# It reads the registry with the Secret `ddm-registry` in `flux-system` —
# the deploy token, as in the `ddm` namespace.
# cms: where its versions are, and which one applies.
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata: { name: ddm-cms, namespace: flux-system }
spec:
  image: registry.gitlab.com/iq-me/new-ddm-images/cms
  interval: 1h
  secretRef: { name: ddm-registry }
---
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata: { name: ddm-cms, namespace: flux-system }
spec:
  imageRepositoryRef: { name: ddm-cms }
  filterTags: { pattern: '^\d+\.\d+\.\d+$' }
  policy: { semver: { range: '0.26.x' } }
---
# render-worker: where its versions are, and which one applies.
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata: { name: ddm-render-worker, namespace: flux-system }
spec:
  image: registry.gitlab.com/iq-me/new-ddm-images/render-worker
  interval: 1h
  secretRef: { name: ddm-registry }
---
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata: { name: ddm-render-worker, namespace: flux-system }
spec:
  imageRepositoryRef: { name: ddm-render-worker }
  filterTags: { pattern: '^\d+\.\d+\.\d+$' }
  policy: { semver: { range: '0.26.x' } }
---
# client: where its versions are, and which one applies.
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata: { name: ddm-client, namespace: flux-system }
spec:
  image: registry.gitlab.com/iq-me/new-ddm-images/client
  interval: 1h
  secretRef: { name: ddm-registry }
---
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata: { name: ddm-client, namespace: flux-system }
spec:
  imageRepositoryRef: { name: ddm-client }
  filterTags: { pattern: '^\d+\.\d+\.\d+$' }
  policy: { semver: { range: '0.26.x' } }
---
# Writes the new versions into ddm.yaml and pushes them.
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageUpdateAutomation
metadata: { name: ddm, namespace: flux-system }
spec:
  interval: 1h
  sourceRef: { kind: GitRepository, name: flux-system }
  git:
    checkout: { ref: { branch: main } }
    commit:
      author: { name: Flux, email: flux@example.com }
      messageTemplate: Update DDM
    push: { branch: main }
  update: { path: ./clusters/production/ddm, strategy: Setters }

Ob Flux etwas gefunden hat, zeigt flux get images all.

Was Sie nicht tun sollten

• Keine Version zurück. Eine neue Version ändert die Datenbank; eine ältere versteht sie danach nicht mehr. Läuft nach einem Update etwas nicht, stellen Sie die Sicherung von vor dem Update wieder her und schreiben Sie uns.
• Postgres nicht automatisch aktualisieren. Eine neue Hauptversion (18 → 19) braucht eine Umstellung der Daten – siehe Postgres.