Zum Inhalt
Getestet, wie es benutzt wird. Kastra ist nicht unter Produktionsbedingungen geprüft — auch der Kanal stabil nicht. Was das heißt.
test 26.10.28.2 stabil 26.10.12.1

Changelog · Fassung

26.10.15.1

Eingriff am Node Test

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.

Geändert

  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.

Behoben

  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Alle Fassungen