update rabbitmq docker containers to v3.12.0

[joeyorlando]

What this PR does

Update rabbitmq Docker containers used in the docker-compose config files, Drone pipelines, and GitHub Actions to use version 3.12.0.

FWIW, we're already using v12.0.0 of the bitnami rabbitmq helm chart which, by default, uses the 3.12.0-debian-11-r0 tag for the rabbitmq image (chart docs).

closes #695

Checklist

• Unit, integration, and e2e (if applicable) tests updated (N/A)
• Documentation added (or pr:no public docs PR label added if not required) (N/A)
• CHANGELOG.md updated (or pr:no changelog PR label added if not required) (N/A)

[roock]

@joeyorlando I think it would make sense to include this in the changelog for multiple reasons:

• Users should be informed to update rabbitmq to a more recent version
• Existing installations will need to perform several intermediate steps to upgrade from 3.7 to 3.12 (see https://rabbitmq.com/upgrade.html#rabbitmq-version-upgradability).

[joeyorlando]

@roock thanks for pointing this out.

this shouldn't have any user facing impact. the two modified docker-compose config files are only used for local development purposes AFAIK. Changes to the rabbitmq version in the helm chart were added to the changelog under v1.2.42.

wdyt?

[roock]

@joeyorlando yes, helm chart is not affected.

I don't agree on the usage of the docker compose files. It's not clear to me that the docker-compose-mysql-rabbitmq.yml version of the docker-compose setup should be considered for development only, for me it is something in between the "hobby" and the "production"(helm) setup.

When I started setting up our Grafana OSS stack somewhen in 2022, there was only one docker-compose file with mysql and rabbitmq included (see #611), that's why I still use this stack and ran into the above issue when upgrading to a recent rabbitmq version.

Probably the docker-compose-mysql-rabbitmq.yml file needs proper documentation on its purpose.

EDIT: And of course the docker-compose-developer.yml is only used for development. But again, you probably want to let the dev team know, that they need to recreate their local stack after pulling in your change! 😉

[joeyorlando]

@roock you raise a fair point 👍 retroactively added this to the changelog in this commit.

re: purpose of docker-compose-mysql-rabbitmq.yml. I believe this was originally the main docker-compose.yml but got refactored in #611 to it's current file name. I don't 100% recall why it stuck around tbh.

Personally, I've been advocating to get rid of this file, as maintaining three separate, but very similar, docker-compose configuration files leads to a larger surface area, and more potential to break something. imo docker-compose-developer.yml should be renamed to docker-compose.yml, as it's the most "fleshed-out" and battle-tested config file. We could then achieve what these three files do, all via the COMPOSE_PROFILES env var. But I digress 🤓

let the dev team know, that they need to recreate their local stack after pulling in your change

We don't have a formal process for this atm. I suppose you could run into issues in the scenario you mentioned, where if you reuse the same rabbitmq Docker volume mount, but upgrade image versions, you'd have to follow those upgrade steps you pointed out. At least on the core team, when people hit these types of problems for local development, they just run make cleanup && make init start. But if you have any suggestions for some, lmk!

[roock]

@roock you raise a fair point 👍 retroactively added this to the changelog in this commit.

👌

re: purpose of docker-compose-mysql-rabbitmq.yml. I believe this was originally the main docker-compose.yml but got refactored in #611 to it's current file name. I don't 100% recall why it stuck around tbh.

Personally, I've been advocating to get rid of this file, as maintaining three separate, but very similar, docker-compose configuration files leads to a larger surface area, and more potential to break something. imo docker-compose-developer.yml should be renamed to docker-compose.yml, as it's the most "fleshed-out" and battle-tested config file. We could then achieve what these three files do, all via the COMPOSE_PROFILES env var. But I digress 🤓

Sounds like a good plan to migrate the two different docker compose files into one with profiles (although I'm not sure docker compose is sophisticated enough to handle such a complex setup).