canasta reconcile

canasta > reconcile

canasta reconcile

Bring an instance's config files and running containers into agreement

Synopsis

Make an instance consistent, without a full restart: its generated config files match their sources, and its running containers match its config files. Safe to run at any time, and the fix for drift reported by 'canasta doctor'.

The most common use is applying edits to config/settings, config/wikis.yaml, .env, or Caddyfile.site. On Docker Compose it recreates only the containers whose configuration changed and reloads Caddy; on Kubernetes it re-syncs the ConfigMaps and runs 'helm upgrade', rolling only the pods whose configuration changed. It also regenerates the Caddyfile, re-derives COMPOSE_PROFILES from the feature flags, starts any containers that should be running but are not, and clears the Varnish cache so no page is served with the old configuration.

On a gitops instance, each generated file and its sources are brought into agreement first, whichever one was edited: config/wikis.yaml with wikis.yaml.template, and .env with env.template and the host's vars.yaml. An edit to .env is written into the sources the way 'canasta config set' writes it; an edit to the sources is rendered into .env, config/wikis.yaml, my.cnf and the admin password files. If the same setting was edited on both sides and they disagree, reconcile stops without changing either. Run 'canasta gitops push' afterwards to share the change.

canasta reconcile [flags]

Examples

canasta reconcile
canasta reconcile --id mysite

Flags

Flag	Shorthand	Description	Default	Required	Orchestrator
--id	-i	Canasta instance ID	*		Both

* Defaults to the Canasta instance matching the current directory, if any.

Global flags

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