Replace DNS-flip failover watcher with static vps.huskypup.net subdomains

The DNS-flip watcher (scripts/vps-dns-failover/) was designed but never
actually installed on the VPS despite being tracked as done - real gap,
found when asked whether the standby services are actually reachable.

New design: instead of dynamically flipping *.kube.huskypup.net between
home and VPS IPs, give the VPS site its own permanent, always-resolving
subdomain - vault/gitea/auth/n8n/nextcloud.vps.huskypup.net, each with
real Ingress+TLS on the VPS's own Traefik+cert-manager (both already
installed by Phase 0 bootstrap, just never wired up). No token-scoping
decision needed since there's no dynamic flipping - reuses the same
cert-manager token pattern as home.

Also scales Authentik/n8n/Nextcloud from 0 to 1 replica on the VPS so
the replicated data is actually browsable at all times, not just
present-but-unreachable. Their CNPG clusters are still read-only
replicas (spec.replica.enabled: true) - writes will error until a
deliberate manual promotion, but reads/browsing work now. Vault and
Gitea were already running continuously.
This commit is contained in:
Scooby Husky
2026-08-18 18:23:08 -05:00
parent f98c997293
commit 5bc1be2f00
13 changed files with 224 additions and 178 deletions
@@ -1,19 +1,20 @@
# Nextcloud warm standby on the VPS - Phase 2. Same discipline as the
# other vps-standby apps: CNPG replica cluster (manifests/cnpg-cluster.yaml)
# keeps the DB warm, manifests/pvc-restore-cronjob.yaml keeps file content
# warm, but the app itself stays at replicaCount: 0 until a deliberate
# manual promotion.
# warm, and the app runs continuously too (replicaCount: 1, reachable at
# nextcloud.vps.huskypup.net - see manifests/ingress.yaml) so replicated
# files/users are browsable at all times - uploads/changes will error
# against the read-only DB until a deliberate manual promotion.
#
# No Redis here - the home instance uses the redis-operator
# (infrastructure/vps-standby has no redis-operator deployed, out of
# scope for a standby that isn't actually serving traffic). Nextcloud
# runs fine without Redis (falls back to DB-based locking, just slower) -
# acceptable for an emergency-promotion scenario; add a real Redis at
# promotion time if desired.
replicaCount: 0
# scope for a standby that isn't actually serving writable traffic).
# Nextcloud runs fine without Redis (falls back to DB-based locking,
# just slower) - add a real Redis at promotion time if desired.
replicaCount: 1
nextcloud:
host: nextcloud.kube.huskypup.net
host: nextcloud.vps.huskypup.net
username: ""
password: ""
@@ -39,7 +40,7 @@ nextcloud:
1 => '172.16.0.0/12',
),
'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'https://nextcloud.kube.huskypup.net',
'overwrite.cli.url' => 'https://nextcloud.vps.huskypup.net',
'allow_local_remote_servers' => true,
);
temp.config.php: |-