Доброго времени суток! Все мы в айти хотим жить без забот, без атак на продукт и проблем с доступом у клиентов. Не хотим, чтобы левые люди и роботы попадали в нашу сеть и имели доступ к эндпоинтам. Для этого древними сисадминами придуман великий и ужасный файрвол. В современных продуктах вроде того же Fortigate можно удобно и крайне точечно рутировать трафик, давать лимитированный доступ по конкретным протоколам и тд.

Но сразу проблема - заполнять это добро из коробки надо ручками. Когда ты настраиваешь корп сеть это не так больно, но когда в твою сеть надо пустить клиентов, у которых много машин с разными адресами, им нужно попасть в разные компоненты твоего продукта, то становится грустно. Особенно, когда это обязанность ложится на руки инженера, который мог бы и более интересными вещами заняться.

Но инженер, тем более девопс, на то и инженер. Видишь что-то, что движется - автоматизируй. Не движется? Двигай и автоматизируй!

Не так давно мы в компании столкнулись с маленькой проблемкой - RabbitMQ (далее просто кроль и тп) на дев кластере упал, мы его оживили, а за definitions.json для восстановления юзеров, очередей и тд. пришлось бегать к разработчику, который по чистой случайности эти файлики часто снимал. Это был первый звоночек.

Вторым звоночком стал DR (Disaster Recovery) - сценарий/упражнение по экстренному поднятию нашего продукта в облаке в случае взрыва и уничтожения нашего физического дата центра. Тут надобность в бэкапах нашего кролика стала очевидной и мы занялись решением этой проблемы

Кратко о том, какие способы управления конфигурацией (создание пользователей, очередей и т. д.) RabbitMQ имеют место быть.