vasyansk
4c9eacccb7
The landing service had no networks: key, so it joined the auto 'default'
network while proxy was only on spaceshell-network + webproxy — they shared no
network, so proxy_pass to 'landing' couldn't resolve. With a static
upstream{ server landing:80 } nginx fails to boot on an unresolvable name and
restart-loops, so the proxy flapped (page intermittently up/down). Fixes:
- landing now joins spaceshell-network (shared with proxy).
- proxy.conf resolves 'landing' at request time via Docker DNS (127.0.0.11)
using a variable proxy_pass, so nginx starts even if landing is briefly down.
nginx -t passes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Deploy — spaceshell.ru
Front nginx (proxy) → landing container, plus /download/spacesh.dmg.
Layout on the server ($SSH_REMOTE_DIR, e.g. /opt/spacesh)
docker-compose.yaml # synced by CI
proxy.conf # synced by CI
download/spacesh.dmg # uploaded locally via `make deploy-dmg`
One-time server setup
# The landing image lives in a private registry — log the server in once:
docker login git.realmanual.ru
mkdir -p $SSH_REMOTE_DIR/download
What runs where
- Landing image + compose deploy → automatic in
.gitea/workflows/build.yamlon push tolanding/**. CI builds/pushes the image, scpsdeploy/*to the server, thendocker compose pull && up -d. - DMG → built on macOS, uploaded by hand:
make deploy-dmg(sets the stabledownload/spacesh.dmg). Tauri can't build a macOS bundle in CI.
Gitea secrets required
SSH_HOST, SSH_USER, SSH_REMOTE_DIR, SSH_KEY (private key, key-based auth).