feat(deploy): Backend auf die stabile Instanz bringen (D77)
Drei Teile, die das Frontend-Deploy nicht braucht: ein eigenes JDK 21 im Home des Servers (dort ist nur 17 installiert, und die Toolchain zu senken hiesse, Entwicklung und Produktion auseinanderlaufen zu lassen), ein systemd-User-Unit statt nohup, und die Proxy-Regel in der .htaccess — gemessen ist, dass das P-Flag auf diesem Hoster erlaubt ist und eine Verbindung 30 s durchhaelt. Der Port steht an genau einer Stelle: deploy-prod.sh setzt ihn in die Proxy-Regel, deploy-backend.sh in die Unit. Zwei Zahlen, die zueinander passen muessen, sind eine zu viel. Die JVM-Flags sind gemessen, nicht geschaetzt. Mein erster Entwurf setzte -Xmx384m; nachgemessen kam heraus, dass die Obergrenze der kleine Hebel ist: Ohne Freiraum-Verhaeltnisse behaelt der Kollektor den gewachsenen Heap, obwohl nach einem GC nur ~45 MB leben. Mit ihnen 174 MB RSS statt 291 MB ohne jede Angabe — auf einem Host mit rund 300 MB frei ist das der Unterschied zwischen "passt" und "draengt die Datenbank weiter in den Swap". Zwei Fallen sind eingebaut, weil beide nur am Ziel auffielen: systemd expandiert kein $HOME (deshalb %h), und `systemctl --user` findet ohne XDG_RUNTIME_DIR seinen Manager nicht. Geprueft bis an die SSH-Grenze: Das Jar startet mit genau den Flags der Unit in einer Sekunde, antwortet auf die Lebendprobe mit 404 und ist von aussen nicht erreichbar; die erzeugte Unit besteht systemd-analyze verify; der ganze Ablauf lief mit gestelltem ssh/rsync durch; deploy-prod.sh liefert die Proxy-Regel mit eingesetztem Port aus. Der Deploy selbst laeuft erst, wenn jemand ihn startet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
ec6fd452b7
commit
4aff995a0e
@@ -24,3 +24,25 @@
|
||||
# ohne Content-Type aus, und Chromium verwirft das Manifest dann still.
|
||||
AddType application/manifest+json .webmanifest
|
||||
</IfModule>
|
||||
|
||||
# --- Backend: /api/ an den eigenen Dienst weiterreichen (D77) ---------------
|
||||
# Der Editor spricht das Backend unter derselben Herkunft an (`?live=…`,
|
||||
# D76). Der Weg dorthin ist mod_rewrite mit dem P-Flag: `ProxyPass` ist in
|
||||
# einer `.htaccess` nicht zulässig, und `~/doms/<domain>/etc/` ist auf diesem
|
||||
# Hoster leer.
|
||||
#
|
||||
# Dass das P-Flag hier ERLAUBT ist, war die offene Frage — manche Hoster
|
||||
# sperren es. Gemessen am 26.08.2026 auf mih00.hostsharing.net: sofortige
|
||||
# Antwort HTTP 200 nach 0,13 s, absichtlich um 30 s verzögerte Antwort
|
||||
# HTTP 200 nach 30,1 s. Apache hält die Verbindung also durch und puffert
|
||||
# nichts weg — Long Polling mit `wait=25` trägt dort nachweislich (D76,
|
||||
# Nachtrag 2).
|
||||
#
|
||||
# Die Portnummer setzt scripts/deploy-prod.sh aus BACKEND_PORT ein; hier steht
|
||||
# ein Platzhalter, damit Port und Dienst nur an EINER Stelle vereinbart sind.
|
||||
# Läuft kein Backend, antwortet /api/ mit 503 — das ist die Wahrheit, und der
|
||||
# Rest der Seite bleibt unberührt.
|
||||
<IfModule mod_rewrite.c>
|
||||
RewriteEngine On
|
||||
RewriteRule ^api/(.*)$ http://127.0.0.1:__BACKEND_PORT__/api/$1 [P,L]
|
||||
</IfModule>
|
||||
|
||||
Reference in New Issue
Block a user