When to run this
Before every engine, containerd or runc upgrade on a host carrying production workloads — including the ones that arrive as part of a routine OS patch cycle, which is how most runtime upgrades actually happen. Budget 30 minutes for the checks and capture the output; a third of the items exist so that you have a “before” to compare against afterwards.
How to run it
Set the stack directory first, and run everything as root or via
sudo — dockerd --validate, the journal query and the package
checks all need it:
STACK_DIR=/srv/stacks/platform
The package items assume Debian or Ubuntu. On RHEL-family hosts the
equivalents are dnf list --showduplicates docker-ce, dnf versionlock list, and ls /var/cache/dnf/*/packages/docker-ce-*.rpm.
Capture the output of current-version-recorded,
storage-driver-recorded and post-upgrade-compare into the change
record. The first two are your rollback target and the third is the
only honest verification that the upgrade did what you expected.
Reading the results
Seven items print only when something is wrong:
live-restore-state-known, no-unhealthy-before,
no-restarting-before, restart-policies-set,
volumes-backed-up, compose-files-committed and
daemon-log-clean. Silence is the pass.
Three items have no command at all — live-restore-limits-understood,
canary-first, drain-plan — because nothing on the host can prove
them. They are the items most likely to be the reason an upgrade goes
badly, so they need a named person’s sign-off rather than a green
tick.
Evidence and sign-off
- Engine / containerd / runc before: ______________________
- Storage driver before: ______________ after: ______________
- Live restore: ______ Canary host and date: ______________
- Operator: _________________ Date: ___________
- Reviewer: ________________ Date: ___________