Tuning an Unreliable, Non-Idempotent Playbook
Scenario Prompt:
“A nightly configuration playbook restarts NGINX on all 50 web servers every run, causing brief traffic drops, even when no configuration files were changed. Investigation reveals a shell task that regenerates an SSL bundle every run. How do you fix this?”
Substantive Technical Concepts to Hit:
Idempotent Task Design
Replace the raw shell task with modules such as community.crypto.x509_certificate (formerly openssl_certificate) or template, which only report a change when the file actually differs.
Changed When Directives
If a custom script must run, use creates to skip it when its output already exists, and changed_when so the task only reports a change when it made one.
Handler Decoupling
Ensure NGINX service restarts are triggered via notify: restart nginx, ensuring handlers only execute when configuration files actually change.
Serial Rolling Restarts
Configure serial: 20% in the play header so restarts occur in batches rather than simultaneously impacting all 50 instances.
- Are servers sitting behind a load balancer that supports health-check draining during the rolling update?
- Can we validate the SSL certificate expiration date programmatically before attempting regeneration?
- What error handling strategy (e.g., max_fail_percentage) should halt the playbook if a batch fails?