8399b87dde
`up -d` kehrt zurueck, sobald der Container LAEUFT — nicht, sobald er antwortet. Der sofortige Griff an die Tuer meldete deshalb bei stetick 502, obwohl nichts kaputt war (drei Sekunden spaeter: 200, dreimal). Ein Riegel, der falsch anschlaegt, wird nach dem dritten Mal ignoriert und bewacht dann gar nichts mehr — dieselbe Begruendung wie bei den Health-Toren im Plattform-Repo. Jetzt fuenf Anlaeufe mit vier Sekunden Pause. Sitzung: 3e9bdf47 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
64 lines
2.8 KiB
Bash
Executable file
64 lines
2.8 KiB
Bash
Executable file
#!/usr/bin/env bash
|
|
# Server-seitiges Deploy der Landing (pageta.com, Port 3201).
|
|
#
|
|
# Voller Flow:
|
|
# lokal: git push
|
|
# Server: ssh mana-server-remote 'zsh -lc "cd ~/projects/pageta && git pull --ff-only && ./apps/landing/deploy-landing.sh"'
|
|
#
|
|
# Das Haupt-`deploy.sh` im Repo-Wurzelverzeichnis fasst die Landing NICHT
|
|
# an („pageta-landing ist separat" steht dort im Kopf) — deshalb dieses
|
|
# zweite Skript. Vorher gab es keines, und der Weg musste aus dem
|
|
# Compose-File und `docker inspect` rekonstruiert werden.
|
|
#
|
|
# 🔴 `-p pageta` IST PFLICHT, und zwar aus zwei Gruenden.
|
|
#
|
|
# 1. Ohne `-p` leitet compose den Projektnamen aus dem VERZEICHNIS des
|
|
# Compose-Files ab. Das ist hier `macmini` — und so heissen auf dem Mac
|
|
# mini rund zehn Dienste. Am 2026-08-16 hat genau das einen Deploy
|
|
# zerschossen: compose legte ein Netz `macmini_default` an, fand den
|
|
# bestehenden Container nicht (der gehoert zu Projekt `pageta`) und
|
|
# brach mit einem Namenskonflikt ab. Der Container lief weiter, aber
|
|
# der Deploy war wirkungslos.
|
|
# 2. In derselben Meldung bot compose `--remove-orphans` an. Wer das in
|
|
# dieser Lage befolgt, loescht die neun fremden Container, die es
|
|
# faelschlich als Waisen dieses Projekts zaehlt: wunsch, mana-domains,
|
|
# buehnenkistli, mana-stiftungen, klangkiste, mana-schaukasten,
|
|
# mana-moodboard, mana-wortlaut, mana-buehne. **Nie `--remove-orphans`.**
|
|
#
|
|
# Hintergrund: mana/docs/DEPLOY_PATTERNS.md und die Memory-Notiz
|
|
# „Compose-Projektname macmini kollidiert".
|
|
set -euo pipefail
|
|
fail() { echo "✗ Landing-Deploy fehlgeschlagen: $*" >&2; exit 1; }
|
|
trap 'fail "unerwarteter Fehler in Zeile $LINENO"' ERR
|
|
|
|
cd "$(dirname "$0")/../.."
|
|
export PATH="/opt/homebrew/bin:/Applications/Docker.app/Contents/Resources/bin:$PATH"
|
|
|
|
COMPOSE="apps/landing/infrastructure/macmini/docker-compose.landing.yml"
|
|
[ -f "$COMPOSE" ] || fail "Compose-Datei fehlt: $COMPOSE"
|
|
[ -f "$HOME/.npm_token" ] || fail "~/.npm_token fehlt (Secret fuer den Build)"
|
|
|
|
echo "→ Bauen und hochfahren (Projekt: pageta)…"
|
|
docker compose -p pageta -f "$COMPOSE" up -d --build
|
|
|
|
echo "→ Tuer anfassen (https://pageta.com/)…"
|
|
# 2xx UND 3xx zaehlen als Antwort — die Hausregel aus deploy:haertung.
|
|
#
|
|
# Mit Anlaeufen: `up -d` kehrt zurueck, sobald der Container LAEUFT, nicht
|
|
# sobald er antwortet. Ein sofortiger Griff an die Tuer meldet dann 502,
|
|
# obwohl nichts kaputt ist — und ein Riegel, der falsch anschlaegt, wird
|
|
# nach dem dritten Mal ignoriert. Genau am 2026-08-16 bei stetick passiert.
|
|
code=000
|
|
for versuch in 1 2 3 4 5; do
|
|
code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 20 https://pageta.com/ || echo 000)
|
|
case "$code" in
|
|
2* | 3*) break ;;
|
|
esac
|
|
sleep 4
|
|
done
|
|
case "$code" in
|
|
2* | 3*) echo " ✓ HTTP $code" ;;
|
|
*) fail "Tuer antwortet nach 5 Anlaeufen mit HTTP $code" ;;
|
|
esac
|
|
|
|
echo "✓ Landing-Deploy fertig."
|