houseofcat
commented
3 years ago Topology is entirely transferrable (i.e. via JSON specifications). I recommend building your topology via file if you can and that way its cluster independent. You simply connect to a new server and build topology.
The Topologer has the ability build everything. https://github.com/houseofcat/turbocookedrabbit/blob/d988bddf1d5cdf1f8359d4a2be8cf44d51c67933/v2/pkg/tcr/topologer.go#L31
Because you can ignore errors you can run it on every app start. It's a slower startup obviously, but its not too bad (this depends on the size of course... YMMV).
We also build top down, exchanges, queues, exchange binding, and queue bindings, so that you can build quite complex structures and dependencies. When building chained dependencies, I used JSON arrays as that will maintain the order of the array and thus you would just mentally need to put the child node (i.e. array[1]) after the parent node (i.e. array[0]) when working out bindings and everything should work.
Barring writing code I don't know what else you would do from my lib. You can extract configurations manually from the Cluster with admin credentials.
If that answers your question, feel free to close out the issue.
istrau2
Is the Topologer similar to a database migration where it will create the queues/exchanges if they do not exist? How is one meant to use the Topologer, as part of the application or as part of a migration? I wouldn't want to put topology changes into my application code, I'd rather run a migration of sorts that updates the RabbitMQ cluster when I am migrating my application(s) to a new version. Is there any way to use the Topologer as part of a migration other than compiling a little app to do just that? Thanks.