Private
Public Access
ksmithandClaude Sonnet 5
7f579bb508
Deployment artifacts for the two-server architecture from ARCHITECTURE.md §9, grounded in verified Debian 13 (trixie) package facts (Python 3.13, PostgreSQL 17, Node.js 20, redis-server 8.0, certbot 4.0, ufw -- confirmed rather than guessed) rather than a generic "modern Linux" guide: deploy/systemd/chatapp.service, deploy/chatapp.env.example, deploy/backup-postgres.sh, deploy/upgrade.sh, and DEPLOYMENT.md as the actual numbered runbook. Revised mid-implementation once the user clarified the app sits behind an existing, separate Nginx Proxy Manager rather than local Nginx+certbot: dropped the local Nginx config entirely, gunicorn now binds a TCP port instead of a Unix socket, and app/main.py gained a static-file mount + SPA fallback route so gunicorn alone serves the built frontend, /api, and /ws on one port -- what lets NPM's simple one-upstream-per-domain mode work with zero custom path routing. Path-traversal-guarded (full_path comes straight from the URL) and cache-header-differentiated (far-future immutable on Vite's content-hashed assets, no-cache on index.html/sw.js/ manifest so a deploy actually propagates instead of leaving clients on a stale service worker) -- verified locally against a real gunicorn process serving a real frontend build, not just eyeballed. Two real gaps found and fixed alongside the docs, not just noted: gunicorn wasn't a dependency anywhere despite being the whole app-server design, and there was no WebSocket reconnect logic on the client -- a reverse proxy's idle-connection timeout (NPM's or otherwise) would have silently killed a quiet chat connection with nothing to recover it. Added exponential-backoff reconnect to useChatSocket.ts, verified by hand (killed and restarted the local dev backend mid-session, confirmed auto-reconnect and that a message sends successfully afterward with no page reload). Every command in DEPLOYMENT.md that could be verified locally, was: the exact systemd ExecStart line run against local dev Postgres/Redis with clean SIGTERM shutdown, the static-file serving behavior against a real build, both shell scripts syntax-checked. What couldn't be verified from this sandbox (actual Debian 13 hardware, Nginx Proxy Manager itself) is flagged explicitly in the plan rather than claimed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
60 lines
1.9 KiB
Bash
Executable File
60 lines
1.9 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Day-2 deploy/upgrade script for the KeepItTalking app server. Run by hand
|
|
# over SSH as the `chatapp` user (or via sudo -u chatapp):
|
|
#
|
|
# sudo -u chatapp /srv/chatapp/deploy/upgrade.sh
|
|
#
|
|
# Fails loudly and stops before touching the running service if any step
|
|
# fails -- the previous deploy keeps running rather than being torn down
|
|
# mid-upgrade. See ../DEPLOYMENT.md for what each step assumes is already
|
|
# in place (venv, /etc/chatapp/env, the systemd unit, Node.js).
|
|
|
|
set -euo pipefail
|
|
|
|
REPO_DIR="/srv/chatapp"
|
|
BACKEND_DIR="${REPO_DIR}/backend"
|
|
FRONTEND_DIR="${REPO_DIR}/frontend"
|
|
ENV_FILE="/etc/chatapp/env"
|
|
|
|
echo "==> Pulling latest code"
|
|
cd "$REPO_DIR"
|
|
git pull --ff-only
|
|
|
|
echo "==> Installing backend dependencies"
|
|
cd "$BACKEND_DIR"
|
|
.venv/bin/pip install -e . --quiet
|
|
|
|
echo "==> Running database migrations"
|
|
# alembic reads DATABASE_URL from the environment (backend/alembic/env.py),
|
|
# so the env file has to actually be sourced into this shell first -- it's
|
|
# not read automatically just because systemd's EnvironmentFile= points at
|
|
# it (that only applies to the chatapp.service process, not this script).
|
|
set -a
|
|
# shellcheck disable=SC1090
|
|
source "$ENV_FILE"
|
|
set +a
|
|
.venv/bin/alembic upgrade head
|
|
|
|
echo "==> Building frontend"
|
|
cd "$FRONTEND_DIR"
|
|
npm ci --silent
|
|
npm run build --silent
|
|
|
|
echo "==> Restarting chatapp"
|
|
# Active WebSocket connections drop here and reconnect automatically within
|
|
# a few seconds (frontend/src/ws/useChatSocket.ts's exponential-backoff
|
|
# reconnect) -- expected, not a bug, and not worth a blue-green setup for.
|
|
sudo systemctl restart chatapp
|
|
|
|
echo "==> Verifying"
|
|
sleep 2
|
|
if curl -sf http://127.0.0.1:8000/api/health >/dev/null; then
|
|
echo "Health check OK"
|
|
else
|
|
echo "Health check FAILED -- check: sudo journalctl -u chatapp -n 50" >&2
|
|
exit 1
|
|
fi
|
|
sudo systemctl status chatapp --no-pager -l | head -10
|
|
|
|
echo "==> Done. journalctl -u chatapp -f to watch logs."
|