canasta upgrade

From Canasta Wiki

canasta > upgrade

canasta upgrade

Upgrade Canasta instances

Synopsis

Upgrade all registered Canasta instances by refreshing configs, pulling latest images, running migrations, and restarting containers. A restarted instance whose startup composer update failed is reported with a warning.

On Docker Compose, upgrade first moves each host's instances behind the HAProxy edge, keeping their hostnames, ports and certificates. A host whose instances the edge cannot all serve is refused with the reason, and none of its instances is upgraded; an instance whose move fails is put back as it was and not upgraded. --dry-run shows each host's plan. Upgrade also renames the TLS settings in each .env: CADDY_TLS_MODE to TLS_MODE (CADDY_AUTO_HTTPS=off to TLS_MODE=off), and CADDY_TRUSTED_PROXIES, CADDY_TLS_CERT and CADDY_TLS_KEY to TRUSTED_PROXIES, TLS_CERT and TLS_KEY.

A Kubernetes instance managed through gitops is not redeployed: Argo CD deploys it from its gitops repo. Upgrade stages the refreshed chart and image tag there, and you deploy them with canasta gitops push, then canasta gitops sync. An instance built from source still has its image rebuilt, and its web pods restart when the new build differs from the image they run.

Upgrade also moves a running instance on the bundled database off the database root account, onto MediaWiki's own mediawiki account with access to the instance's wiki databases only. It leaves the instance on root, and says why, while a settings file sets $wgDBuser or $wgDBpassword or the server holds a database no wiki declares, and tries again on the next upgrade. canasta config set CANASTA_DB_ROOT_ACCOUNT=true keeps an instance on root. On a gitops-managed Kubernetes instance the move is staged with the rest and takes effect at the push and sync.

By default the CLI itself updates to the latest released version within the current major (the highest vX.Y.Z tag whose major matches the installed version), so an upgrade never crosses a major boundary on its own. Pass --allow-major to move to the latest release overall, including a new major version (which may include breaking changes). Pass --dev to track the development branch (head of main) instead.

Pass --purge to reclaim disk after the upgrade: each upgraded host has the Canasta images the upgrade superseded removed (never one an instance on that host is pinned to, running or stopped), dangling sidecar-rebuild layers pruned, and — on Kubernetes — the in-cluster registry garbage-collected. Volumes are never touched. canasta image prune runs the same reclaim on one host without upgrading anything.

canasta upgrade [flags]

Examples

canasta upgrade
canasta upgrade --allow-major
canasta upgrade --dev
canasta upgrade --dry-run
canasta upgrade --purge

Flags

Flag Shorthand Description Default Required Orchestrator
--allow-major Allow upgrading across a major version boundary to the latest release overall (may include breaking changes) Both
--dev Track the development branch (head of main) instead of the latest release Both
--dry-run Preview changes without applying Both
--purge After upgrading, reclaim disk by removing images the upgrade superseded (never removes in-use images or volumes) Both

Global flags

Flag Shorthand Description Default Required Orchestrator
--help -h Show help message and exit Both
--verbose -v Enable verbose output Both