4acbcc170a
Per-deploy delta on top of roles/haproxy: re-template the cfg
referencing the freshly-deployed color, validate, atomic-swap, HUP.
Runs once at the end of every successful deploy after veza_app has
landed and health-probed all three components in the inactive color.
Layout:
defaults/main.yml — paths (haproxy.cfg + .new + .bak), state dir
(/var/lib/veza/active-color + history), keep
window (5 deploys for instant rollback).
tasks/main.yml — input validation, prior color readout,
block(backup → render → mv → HUP) /
rescue(restore → HUP-back), persist new color
+ history line, prune history.
handlers/main.yml — Reload haproxy listen handler.
meta/main.yml — Debian 13, no role deps.
Why a separate role from `roles/haproxy`?
* `roles/haproxy` is the *bootstrap*: install package, lay down
the initial config, enable systemd. Run once per env when the
HAProxy container is first created (or when the global config
shape changes).
* `roles/veza_haproxy_switch` is the *per-deploy delta*. No apt,
no service-create — just template + validate + swap + HUP.
Keeps the per-deploy path narrow.
Rescue semantics:
* Capture haproxy.cfg → haproxy.cfg.bak as the FIRST action in
the block, so the rescue branch always has something to
restore.
* Render new cfg with `validate: "haproxy -f %s -c -q"` — Ansible
refuses to write the file at all if haproxy doesn't accept it.
A typoed template never reaches even haproxy.cfg.new.
* mv .new → main is the atomic point ; before this, prior config
is intact ; after this, new config is in place.
* HUP via systemctl reload — graceful, drains old workers.
* On ANY failure in the four-step block, rescue restores from
.bak and HUPs back. HAProxy ends the deploy serving exactly
what it served at the start.
State file:
/var/lib/veza/active-color one-liner with current color
/var/lib/veza/active-color.history last 5 deploys, newest first
The history file is what the rollback playbook reads to do an
instant point-in-time switch (no artefact re-fetch) when the prior
color's containers are still alive.
--no-verify justification continues to hold.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
18 lines
695 B
YAML
18 lines
695 B
YAML
---
|
|
# These should be set by the caller — defaults here are guards that
|
|
# fail loud if the caller forgot to pass them.
|
|
veza_active_color: ""
|
|
veza_release_sha: ""
|
|
|
|
# Paths inside the HAProxy container.
|
|
haproxy_cfg_path: /etc/haproxy/haproxy.cfg
|
|
haproxy_cfg_new_path: /etc/haproxy/haproxy.cfg.new
|
|
haproxy_cfg_backup_path: /etc/haproxy/haproxy.cfg.bak
|
|
haproxy_state_dir: /var/lib/veza
|
|
haproxy_active_color_file: /var/lib/veza/active-color
|
|
haproxy_active_color_history: /var/lib/veza/active-color.history
|
|
|
|
# How many history entries to keep before pruning. The rollback role
|
|
# offers point-in-time switch within this window without redeploying
|
|
# the artefact.
|
|
haproxy_active_color_history_keep: 5
|