refactor: extract backup/restore into config scripts, trim comments
All checks were successful
cc-ci/testme cc-ci: success

Move the postgres and clickhouse backup/restore hook logic out of inline
compose labels into dedicated pg_backup.sh / clickhouse_backup.sh config
scripts (the pattern other recipes use), and trim the verbose explanatory
comments down to the essential rationale, now living in the scripts.
This commit is contained in:
notplants
2026-06-10 16:55:20 +00:00
committed by notplants
parent 270c8404ce
commit 13458fac56
5 changed files with 88 additions and 45 deletions

View File

@ -1,22 +1,9 @@
#!/bin/bash
# clickhouse-backup powers this recipe's backup/restore (the backupbot pre/post-hooks run
# `clickhouse-backup create/restore`). A deploy without it would have silently broken backups,
# so if it truly cannot be installed the deploy must FAIL LOUDLY rather than degrade.
#
# The published recipe fetched it with a single silenced no-retry wget at every container start:
# any transient GitHub failure exited the container (set -e) before clickhouse-server started,
# and the swarm restart loop re-downloaded the 22 MB asset on every restart, amplifying a
# throttle into a permanent crash-loop and a deploy timeout (cc-ci Q4.7).
#
# Hardening (no behaviour change when the fetch succeeds first try):
# - cache the VERIFIED binary on the persistent clickhouse volume, keyed by version, so it is
# downloaded at most once per app and container restarts never re-fetch;
# - canonical Altinity URL (the project moved; the old AlexAkulov path is just a redirect);
# - bounded retries with backoff + a read timeout, so a stalled connection cannot hang the
# deploy and a transient failure cannot kill it;
# - verify the binary actually executes before trusting or caching it (catches truncated
# downloads and a corrupt cache);
# - un-silenced: every attempt and the final verdict are visible in `docker service logs`.
# Install clickhouse-backup (powers this recipe's backup/restore hooks) before starting the
# server. The binary is cached on the persistent volume keyed by version (downloaded at most
# once per app) and fetched with bounded retries + a read timeout; the binary is verified before
# being trusted or cached. If it truly cannot be installed the deploy fails loudly rather than
# silently shipping broken backups.
set -e