Neuer Chart: valkey - eine Instanz je Anwendung statt der geteilten Redis #46
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jlab-cluster/helm-charts#46
Reference in new issue
Block a user
Ein Inhouse-Chart
valkeyfür einzelne Cache- und Warteschlangen-Instanzen, je Anwendung eine — als Ersatz für die geteilte Instanzcluster-redis.Warum
cluster-redisversorgt heute sechs Anwendungen (OneUptime auf Index 2, Outline, drei Paperless-Instanzen; Stand 26.09.2026). Die Trennung läuft über eine ACL-Datei in einem einzigen 1Password-Feld (cluster-redis, Feldusers.acl), und daran hängt alles:sure) ist genau so ein Fall und hat die Namespace-Unterstützung ab Version 7 entfernt.users.aclbetrifft sechs Anwendungen und braucht einen Redis-Neustart, damit sie greift. Der Kommentar incluster-config/fleet-cd/jlab-git/gitea/jlab-git.values.yamlhat genau deshalb schon entschieden, Gitea nicht dort anzuschließen: „Ein weiterer Nutzer waere eine Aenderung an einem Element, an dem alle anderen Verbraucher mit haengen."cluster-config#102): Paperless 3.0 legte Celery-Ergebnisse als unprefixtecelery-task-meta-*-Schlüssel ab, die ACL lehnte sie ab, und die MeldungNoPermissionErrortauchte nur im Worker-Log auf.Mit einer Instanz je Anwendung verschwindet die ACL-Frage ersatzlos: Jede darf
~*, weil sie allein ist.Das Abbild: offiziell, nicht Bitnami
docker.io/valkey/valkey, nichtbitnamicharts/valkey. Der Bitnami-Chart existiert (6.3.3, App 9.1.2), aber Bitnami führt seit August 2025 nur nochlatest— die Folge steht bereits fünfmal incluster-configalstag: "latest@sha256:…", zweimal davon ausgerechnet incluster-redisselbst. Renovate sieht das offizielle Abbild dagegen ohne Kunstgriff (es schlägt gerade einen Digest fürvalkey:9.1-alpinevor).Gewünschte Merkmale
Grundform
scaleDown-Schalter chart-global, wie in den übrigen Inhouse-Charts.values.schema.jsonmitadditionalProperties: false. Hat sich bewährt: ein verschriebener Schlüssel scheitert beim Rendern statt still ignoriert zu werden.NOTES.txt, das die Pflichtfelder des 1Password-Eintrags namentlich aufzählt — nach dem Muster dessure-Charts. Ein fehlendes Feld ergibt sonstCreateContainerConfigErrorund keinen Render-Fehler.Speicher
persistence.enabledumschaltbar. Für Warteschlangen (Sidekiq, Celery) an, für reine Zwischenspeicher aus.longhorn-encrypted-ns, Vorgabe klein (1Gi). Auf verschlüsselten Longhorn-Volumes wird Platz nie zurückgegeben — lieber knapp anfangen.appendonlyals Wert, mit Begründung im Kommentar: Für Warteschlangen ist AOF die haltbarere Wahl, RDB verliert im Zweifel die letzten Minuten.Verdrängung — der wichtigste Standardwert
maxmemory-policyals Wert, Vorgabenoeviction. Nichtallkeys-lru: Unter Druck würde Redis/Valkey sonst die Celery- beziehungsweise Sidekiq-Warteschlange wegwerfen, und die Anwendung bliebe dabei grün. Das war eine der Hypothesen beicluster-config#102und ist hier billiger zu verhindern als zu diagnostizieren.maxmemorypassend zum Speicher-Limit setzen, nicht darüber — sonst holt das OOM-Kill des Kubelet, was die Verdrängungsregel hätte regeln sollen.Zugang
OnePasswordItem, das der Chart selbst rendert (secrets.authSecretRef), niemals als Literal. Feldname imNOTES.txtdokumentiert.--requirepassüber Umgebung, nicht als Argument — sonst steht es in der Prozessliste.Härtung und Ressourcen
runAsNonRoot, feste UID/GID,fsGrouppassend zum Volume,readOnlyRootFilesystem: true, alle Capabilities weg,seccompProfile: RuntimeDefaultim Pod-Kontext (damit Init-Container mitgedeckt sind).emptyDir, soweit nötig.ephemeral-storageaus den Requests berechnet, kein CPU-Limit als Vorgabe.redis-cli pingbeziehungsweisevalkey-cli pingals Exec-Probe. Kein HTTP.Versionierung
<chartVersion>+up<appVersion>, wie alle Inhouse-Charts.Erster Abnehmer:
surecluster-config#110bereitet das Deployment von Sure vor und lässt die Redis-Frage bewusst offen, weil der Chart die Verbindung als fertigeredis://-Adresse aus dem Tresor bekommt. Sure läuft noch nicht — damit ist es der risikofreie Erstversuch für diesen Chart: Es gibt keine Warteschlange zu verlieren und keinen ACL-Nutzer zu entfernen.Danach, je Anwendung verschieden
Reihenfolge immer: Instanz ausrollen →
connection-urlim Tresor umbiegen → Pods neu starten → prüfen → zuletzt den ACL-Nutzer aususers.aclentfernen, damit ein Rückfall möglich bleibt.db1, 3 Schlüssel) — praktisch aufwandsfrei, guter zweiter Schritt.cluster-config#102).db2, 33 426 Schlüssel und wachsend) — zuletzt. Hier heißt Umziehen: Warteschlangen leer laufen lassen oder Verlust in Kauf nehmen.Der gemeinsame Bestand liegt bei 464 MB, fast vollständig OneUptime. In Summe entsteht also kein neuer Speicherbedarf, er verteilt sich nur.
Freigegebener Umsetzungsplan (Manager-Sitzung, 2026-09-27). Die Anforderungen im Issue-Text gelten unverändert; hier stehen die verifizierten Fakten, vier Entscheidungen und drei Punkte, die nicht angenommen werden dürfen.
Verifiziert, nicht aus der Erinnerung
Gegen die Registry abgefragt:
9.1.2-alpine3.24(unveränderlich),9.1.2-alpine(wandert mit der Alpine-Basis) und9.1-alpine(wandert mit jedem Patch). Der im Issue genannte9.1-alpinetaugt damit nicht alsappVersion.Usernicht — es startet als root. Wie bei Redis lässt der Entrypoint (tini -- docker-entrypoint.sh) die Rechte per gosu auf den Benutzervalkeyfallen. Startet der Pod direkt als uid 999, wird dieser Schritt übersprungen. Das ist bei der Umsetzung zu bestätigen, nicht vorauszusetzen.WorkingDir: /data,Cmd: valkey-server, kein deklariertes Volume.Entschieden
appVersion: 9.1.2-alpine3.24, Chart1.0.0+up9.1.2.alpine3.24(Bindestriche im Suffix zu Punkten). Vollständig unveränderlicher Tag.--requirepassin der Prozessliste. Der Feldname wird inNOTES.txtnamentlich dokumentiert.Die Folge von Entscheidung 1, die niemand später als Versäumnis lesen soll
Ein vollständig unveränderlicher Tag bindet die Alpine-Basis mit ein — und Docker-Versionierung bietet nur Kandidaten mit demselben Suffix an. Das steht in der README schon einmal, als Begründung für die nginx-Einschränkung: Eine suffix-blinde Regel friert ein Abbild stillschweigend ein, sobald sich das Suffix ändert.
Hier heißt das: Sobald Valkey auf
alpine3.25wechselt, wird Renovate keine Aktualisierung mehr anbieten, und nichts meldet es. Das gehörtrenovate.json5-Block,Wer den Block schreibt, prüft per Probelauf, dass die Regel überhaupt greift — nach der Regel aus der README: Eine gültige Regel ist keine passende Regel, und „keine Aktualisierung" sieht bei einer funktionierenden und einer kaputten Regel gleich aus.
Die Folge von Entscheidung 2, die abgesichert werden muss
Eine fertige Konfigurationszeile im Tresor heißt: Ist das Feld verschrieben —
requirepas, falsche Anführungszeichen, leer —, startet Valkey ohne Passwort und ist gesund. Kein Render-Fehler, kein Absturz, ein offener Server.Deshalb prüft ein Init-Container die gemountete Datei und bricht ab, wenn keine Zeile mit
requirepassdarin steht. Das ist kein Widerspruch zu Entscheidung 2: Er setzt die Konfiguration nicht zusammen, er prüft sie nur. Das Passwort landet dabei in keiner Ausgabe.Persistenz und Verdrängung sind ein Paar, nicht zwei Werte
Die Vorgabe
noevictionist für eine Warteschlange richtig und für einen Zwischenspeicher falsch: Bei vollem Speicher lehnt Valkey dann Schreibvorgänge ab, statt kalte Schlüssel zu verwerfen. Invalues.yamlgehören deshalb die beiden sinnvollen Paare dokumentiert:persistence.enabled: true+maxmemory-policy: noevictionpersistence.enabled: false+maxmemory-policy: allkeys-lrumaxmemorywird aus dem berechneten Speicher-Limit abgeleitet, und ein konfigurierter Wert über dem Limit bricht den Render mitfailab — sonst holt das OOM-Kill des Kubelet, was die Verdrängungsregel regeln sollte.Was gemessen werden muss, nicht angenommen
valkey-cli pingantwortet ohne Authentifizierung mitNOAUTH. Ob der Rückgabewert dann ungleich null ist, entscheidet, ob die Probe etwas prüft. Mit absichtlich falschem Passwort gegentesten — eine Probe, die nicht scheitern kann, ist die Fehlerklasse, die dieses Repo am häufigsten teuer bezahlt hat.checksum/config? Die Hauptkonfiguration kommt als ConfigMap, also ist die Annotation nach Richtlinie 9 Pflicht. Das Passwort-Secret ist davon nicht erfasst (Helm sieht seinen Inhalt nie) — dafürchecksum/secret-refüber das gerenderteOnePasswordItem.Erster Abnehmer
sure, weil es noch nicht läuft: keine Warteschlange zu verlieren, kein ACL-Nutzer zu entfernen. Das Chart bekommt seine Verbindung als fertigeredis://-Adresse aus dem Tresor, also ist keine Änderung am sure-Chart nötig — nur ein Eintrag im Tresor und das Ausrollen der Instanz. Die Reihenfolge für alle weiteren Abnehmer steht im Issue und bleibt unberührt.Nachtrag zu Entscheidung 1: Der unveränderliche Tag bleibt — aber er braucht eine Regex-Versionierung, keine Docker-Versionierung. Vorgabe des Betreuers: Renovate muss einen Wechsel auf
alpine3.25mitbekommen und vorschlagen.Gemessen: Upstream bindet die Basis an die Version
Ausgewertet über den Tag-Bestand von
valkey/valkey:Je Valkey-Version existiert genau eine Alpine-Basis: die zur Zeit des Releases aktuelle. Ältere Basen (3.19 bis 3.23) tragen nur ältere Valkey-Versionen. Upstream baut alte Versionen also nicht gegen neue Basen nach.
Folge: Ein Wechsel auf
alpine3.25erscheint nicht als9.1.2-alpine3.25, sondern als9.1.3-alpine3.25oder9.2.0-alpine3.25. Docker-Versionierung, die nur Kandidaten mit demselben Suffix anbietet, würde auf ein9.1.3-alpine3.24warten, das nie gebaut wird — das Chart fröre beim nächsten Basiswechsel ein. Der Einwand von vorhin ist damit belegt, nicht bloß vermutet.Die Regel
Im
customManagers-Block eineversioningTemplatemit einem Ausdruck, der beide Versionen als sortierbare Felder erfasst:major/minor/patchsind Valkey,build/revisionsind die Alpine-Basis (3 und 24).major,minor,patch,buildundrevisionmitNumber.parseInt, und eine nicht-numerische Gruppe wird zu den führenden Ziffern oder zuNaN.-alpineschließt9.1.2-trixieund das nackte9.1.2aus, ohne sie zu erwähnen.compatibility-Feld. Es würde genau die Suffix-Bindung wiederherstellen, die hier das Problem ist.Damit ordnet Renovate über Suffixgrenzen hinweg und bietet
9.1.3-alpine3.25an.Was daran ungeprüft bleibt, und wie es geprüft wird
Im Arbeits-Workspace gibt es kein node, npm oder npx — ein Renovate-Probelauf ist hier nicht möglich (bei #34 schon festgestellt, dort konnte auch
renovate-config-validatornicht laufen). Die Regel ist also bis zum ersten Lauf auf der Instanz unbelegt, und genau so gehört sie im PR benannt.Die Abnahme ist damit nicht mit dem Merge erreicht, sondern erst, wenn eines von beiden vorliegt:
valkeyim Dependency Dashboard erscheint.Das ist nicht Formalie: Bei einer Digest- oder Versionierungsregel sehen eine funktionierende und eine nicht passende Regel identisch aus, solange die gepinnte Version aktuell ist — beide erzeugen nichts. Genau das steht als Lehre im Wiki.
Unverändert
Die übrigen drei Entscheidungen und alles andere aus dem Plan-Kommentar oben bleiben, wie sie sind: unveränderlicher Tag
9.1.2-alpine3.24, Passwort als Konfigurationszeile aus dem Tresor mit prüfendem Init-Container, Install-Test mit Persistenz, NetworkPolicy standardmäßig an.Entscheidung 1 revidiert (Betreuer):
appVersion: 9.1.2-alpine, nicht9.1.2-alpine3.24. Damit entfällt die Regex-Versionierung aus dem Nachtrag oben ersatzlos.Warum das besser ist, als ich es vorher dargestellt habe
Ich habe
-alpine3.24als „vollständig unveränderlich" bezeichnet. Das war falsch. Die Erstellungszeitpunkte widerlegen es:Zwei verschiedene Versionslinien, am selben Tag innerhalb von Minuten gebaut — 9.0.6 ist ein älteres Release. Upstream baut also die gesamte Tag-Matrix periodisch neu, und auch der Tag mit Basis-Nummer wird dabei neu gepusht. Unveränderlich ist an einem Tag nichts; das ist allein ein Digest.
Die Wahl stand also nie zwischen „unveränderlich" und „wandernd", sondern zwischen zwei gleich wandernden Tags mit unterschiedlichem Renovate-Verhalten. Damit ist
-alpinedie klar bessere Wahl.Was jetzt gilt
appVersion: 9.1.2-alpine, Chart1.0.0+up9.1.2.alpine.versioningTemplate. Docker-Versionierung trennt am ersten Bindestrich, liest9.1.2als Version undalpineals Kompatibilitäts-Suffix. Angeboten werden9.1.3-alpine,9.2.0-alpine— das Suffix bleibt für immer gleich, also kann die Bindung nie einfrieren.9.1.3-alpineträgt die neue Basis, ohne dass wir sie benennen müssen.renovate.json5ist damit der einfachste im ganzen Repo: Abbildpfad und Standard-Versionierung, kein Sonderfall, nichts zu beweisen. Die unbelegbare Regel aus dem Nachtrag ist vom Tisch — das ist der eigentliche Gewinn, denn ohne node ließ sie sich hier nicht prüfen.Der Preis, ausdrücklich benannt
Ein wandernder Tag heißt: Wird
9.1.2-alpineneu gebaut, ändert sich das laufende Abbild ohne Änderung im Repository, und nichts meldet es. Das ist dieselbe Klasse, die bei #51 untersucht wurde — dort hat sich der Verdacht zwar nicht bestätigt, die Sorge war aber berechtigt.Falls das je zählt, steht das Gegenmittel bereit:
pinDigestsfür dieses eine Abbild einschalten. Global ist es seit #34 fürcustom.regexundhelm-valuesabgeschaltet, eine Ausnahme je Chart ist aber möglich. Das gehört als Satz in den Renovate-Block, damit der nächste Leser die Wahl kennt, statt sie neu herzuleiten.Unverändert
Passwort als Konfigurationszeile aus dem Tresor mit prüfendem Init-Container, Install-Test mit Persistenz, NetworkPolicy standardmäßig an, Paarbildung von Persistenz und Verdrängungsregel, und die drei Punkte, die gemessen statt angenommen werden.
Nachtrag, damit die letzte offene Prüfung aus PR #53 nicht offen bleibt: Der Renovate-Block greift.
Im Dependency Dashboard steht jetzt unter „Detected Dependencies":
Damit ist belegt, was in der PR-Beschreibung ausdrücklich als unbelegt markiert war — ein Probelauf war hier nicht möglich, weil im Arbeits-Workspace node fehlt. Renovate erkennt den Abbildpfad aus dem
customManagers-Block und liest dieappVersionals Version. Keine offene Aktualisierung, korrekt: 9.1.2 ist aktuell.Wichtig ist dabei die Art des Belegs: Das Dashboard führt einen Abschnitt „Detected Dependencies", der alles auflistet, was erkannt wird — nicht nur Fälliges. Ohne diesen Abschnitt hätte „valkey erscheint nicht" nichts bedeutet, weil eine passende und eine nicht passende Regel bei aktueller Version dasselbe Ergebnis liefern: keines. So ist das Fehlen eine Aussage und die Anwesenheit ein Nachweis.
Offen bleibt aus #53 nur noch, dass
fsGroupselbst unter den knoten-verzeichnis-gestützten Volumes von k3d nicht bewiesen ist — Schreibbarkeit ja, Eigentümer-Mechanismus nein. Das steht so invalues.yamlund auf der Wiki-Seite.