48 lines
2.3 KiB
Markdown
48 lines
2.3 KiB
Markdown
|
# `veza_haproxy_switch` role
|
||
|
|
|
||
|
|
Atomically swap HAProxy's active color. Runs against the
|
||
|
|
`{{ veza_container_prefix }}haproxy` container after `veza_app` has
|
||
|
|
recreated + health-probed all three components in the inactive color.
|
||
|
|
|
||
|
|
## Why a separate role from `haproxy`?
|
||
|
|
|
||
|
|
- `roles/haproxy` provisions a fresh HAProxy container — install
|
||
|
|
the package, lay down the *initial* config, enable the systemd
|
||
|
|
unit. It runs once when the staging/prod env is bootstrapped and
|
||
|
|
occasionally when the global config shape changes.
|
||
|
|
- `roles/veza_haproxy_switch` performs the *per-deploy* delta —
|
||
|
|
re-template the cfg with a new `veza_active_color`, validate,
|
||
|
|
swap, HUP. It runs once at the end of every successful deploy.
|
||
|
|
|
||
|
|
Splitting them keeps the per-deploy path narrow (no apt, no service
|
||
|
|
install) and lets `roles/haproxy` remain idempotent when the global
|
||
|
|
shape hasn't changed.
|
||
|
|
|
||
|
|
## Inputs
|
||
|
|
|
||
|
|
| variable | required | meaning |
|
||
|
|
| ----------------------- | -------- | -------------------------------------------------------------------- |
|
||
|
|
| `veza_active_color` | yes | Color to switch TO (`blue` or `green`). Becomes the new active. |
|
||
|
|
| `veza_release_sha` | yes | SHA being deployed. Logged in the active-color history file. |
|
||
|
|
| `veza_container_prefix` | inherit | From group_vars/<env>.yml. |
|
||
|
|
| `haproxy_topology` | inherit | Should be `blue-green` for this role to make sense. |
|
||
|
|
|
||
|
|
## Failure semantics
|
||
|
|
|
||
|
|
The render → validate → atomic-swap → HUP sequence runs in an
|
||
|
|
Ansible `block:` with a `rescue:` that restores `haproxy.cfg.bak`
|
||
|
|
(captured before the swap) and re-HUPs. So an invalid config or a
|
||
|
|
HUP failure leaves HAProxy serving the *previous* active color
|
||
|
|
exactly as before — the deploy as a whole then fails on the playbook
|
||
|
|
level.
|
||
|
|
|
||
|
|
## What the role does NOT do
|
||
|
|
|
||
|
|
- It does not destroy or recreate the HAProxy container. That's a
|
||
|
|
one-time operation under `roles/haproxy`.
|
||
|
|
- It does not touch app containers — by the time this role runs,
|
||
|
|
blue/green app containers are both healthy.
|
||
|
|
- It does not remove the previously-active color's containers. They
|
||
|
|
survive (intentional) so a rollback can flip back instantly. The
|
||
|
|
next deploy naturally recycles them.
|