RabbitMQ Definitions Export & Import GitOps Prompt
Treat RabbitMQ topology as code — export definitions, scrub secrets, version them, and import safely on boot so brokers are reproducible instead of hand-configured.
- Target user
- Platform and SRE engineers managing RabbitMQ as code
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who manages RabbitMQ topology as code via definitions export/import. Help me set up a safe, reproducible GitOps flow. I will provide: - What I want versioned: vhosts, users, permissions, queues, exchanges, bindings, policies, parameters [DESCRIBE] - How brokers are deployed: container image, config-managed VM, or operator, and the boot process [DESCRIBE] - Secret-handling constraints: where passwords/hashes can and can't live [DESCRIBE] - Cluster version and whether I'll import at boot (`load_definitions`) or via the management API [DESCRIBE] Your job: 1. **Export cleanly** — show `rabbitmqctl export_definitions` (or the management API), and flag that the export contains user password HASHES and policy details. Make clear what must be scrubbed or templated before it goes in git. 2. **Secret handling** — recommend keeping password hashes out of version control: template users/permissions and inject hashes at deploy time, or manage users separately from topology. Never commit raw credentials. 3. **Idempotent import** — explain that `load_definitions` on boot is additive/declarative and safe to re-run, but that it does NOT delete objects removed from the file (no pruning). Plan how removed queues/policies get cleaned up, since drift accumulates otherwise. 4. **Validate before apply** — recommend importing into a throwaway/staging broker first, diffing the resulting topology against intent, and only then promoting. Show how to catch a malformed definitions file before it hits a real node. 5. **Confirm** — after import, verify with `rabbitmqctl list_queues`, `list_policies`, `list_permissions` that the live topology matches the file. Output as: (a) the export command and what to scrub, (b) the secret-handling pattern, (c) the boot-time `load_definitions` config and the no-pruning caveat with a cleanup plan, (d) the staging validate-and-diff step, (e) the post-import verification commands. Always import into a staging broker and diff against intent before applying to production. Remember definitions import does not prune removed objects — verify there's no leftover drift, and confirm no secrets landed in the committed file.
Why this prompt works
Managing RabbitMQ topology as code is the right instinct, and definitions export/import is the supported way to do it — but the export is not safe to commit as-is, and the import does not behave the way GitOps muscle memory expects. This prompt front-loads both gotchas. The export contains user password hashes and the full topology, so dropping it straight into git leaks credentials; the prompt makes scrubbing or templating secrets a first-class step rather than an afterthought.
The import behavior is the bigger conceptual trap. load_definitions is declarative and additive and safe to re-run, which lulls people into treating it like a full reconciler — but it never deletes objects that were removed from the file. There’s no pruning. Remove a queue or policy from your versioned definitions and it lingers on every broker indefinitely, so drift quietly accumulates. By calling this out and demanding an explicit cleanup plan, the prompt prevents the slow rot that turns “infrastructure as code” back into hand-configured brokers.
The validate-and-diff step is what makes the flow trustworthy. Importing into a throwaway staging broker, diffing the resulting topology against intent, and verifying with list_queues / list_policies / list_permissions catches both malformed files and unexpected drift before production sees them. The guardrails keep two failures out: committed secrets and silent leftover objects — the two things that most often turn a tidy GitOps story into an incident.