Tags: heyvaldemar/zabbix-docker-compose
Tags
ci: an upgrade drill before the deploy smoke; update.sh names new req… …uired variables The deploy job now starts the previous release first, on the same volumes, waits for it to be healthy, stops it and keeps the volumes; the ordinary up -d that follows recreates the changed containers on top of it, which is what git pull and docker compose up -d do on a deployed host. Every smoke check after it judges the upgraded stack. When the compose file is unchanged since the last release the drill says so. update.sh lists the variables that appeared in .env.example since the version you are on and refuses, before anything has moved, when a required one is not in your .env. Names only, never values. Repositories that had no update.sh get the fleet one: release tags only, no unattended major, no run over local changes.
fix: a backup killed halfway no longer looks like a finished one The loop already renamed a failed dump to .failed so nothing would restore from it. That rename only runs if the shell lives long enough to reach it, and a container stopped mid-dump does not: the truncated file keeps the name a finished backup would have, and it is the newest, which is exactly what the restore script and the end-to-end test select. Every backup is now written to <name>.partial and renamed only once the dump has succeeded. The real name never exists unless the file behind it is whole.
fix: give the database and cache time to shut down Docker stops a container with SIGTERM and ten seconds, then SIGKILL. That default is not always enough. PostgreSQL has a checkpoint to write, MariaDB has InnoDB to flush, and Redis saves its dataset on the way out. Killed halfway, the next start does crash recovery, and a Redis holding another application's file locks leaves them behind for a person to clear by hand. Sixty seconds now, overridable per service with <PREFIX>_STOP_GRACE_PERIOD in .env. The backup sidecar is deliberately left alone: killing it mid-dump leaves a truncated file under the name the restore path would pick, and a longer grace period does not fix that.
fix(tests): a backup file counts only once the loop has logged it OK A file that exists under the backups path may still be being written; the content check read a half-written archive and failed without anything being wrong. The post-marker lookup now waits for the "backup OK" log line that names the file.
fix(security): apply the hardening to the first service in the file too The generator skipped the first service under services:, so one container per file (the reverse proxy or the database, depending on order) shipped without security_opt and cap_drop. Now every service carries the settings the changelog describes.
feat: resource limits on every service as .env-overridable defaults Each service now carries memory and CPU limits plus reservations as compose-level defaults (<SERVICE>_MEMORY_LIMIT, _CPU_LIMIT, _MEMORY_RESERVATION, _CPU_RESERVATION, all listed in .env.example). Set any of them in .env and the override survives every git pull. The defaults are what CI boots the stack under, so a fresh install is known to fit; raise a limit if a service is OOM-killed under real load.
fix(tests): judge dump content on a backup taken after the marker Some applications create their schema only after the setup wizard, so the newest dump at test time can be legitimately empty apart from the marker table - and the marker may postdate that dump. The content check now waits for the first backup taken after the marker, the same backup the restore roundtrip uses.
fix(backups): report a failed dump instead of hiding it The backup loop piped the dump into gzip and only checked gzip's exit status, so a dump that failed halfway - database down, wrong password, disk full - still left a small .gz that looked like a backup. The loop now runs with pipefail, logs 'Database backup OK: <file> (<bytes>)' or 'Database backup FAILED' per cycle, keeps a failed dump as <file>.failed for diagnosis, and prunes only its own files (retention 0 disables pruning instead of deleting everything). CI now waits for the first backup cycle and proves the produced archive is readable and carries a real dump header.