По Inventory. Он лежит в отдельном контейнере полностью соответствует ABP. Здесь описывал архитектуру - https://habr.com/ru/companies/pt/articles/896652/. Подключается по WebDAV в каждый А-сервис. Это помогает запустить любое количество Inventory и любых версий. Доработку Inventory можно делать независимо, а это сильно сокращается трудозатраты. (У нас еще разрабатывается UI, в котором графически можно нарисовать сложную структуру офиса и она конвертируется в inventory.yml). Это я всё к тому, если Inventory статичен, не дорабатывается, интеграция внутри и наружу минимальная, то такая архитектура с выносом в отдельный контейнер кажется избыточна, но у нас не так.
По ролям. У нас их больше 300. A-service около 150. Что такое роль у нас? Это, конечный сценарий выполняющие унарную конфигурацию. К примеру: роль - linux_user (создание пользователя, удаление, модификация), роль - linux_group (создание группы, удаление, добавление пользователей). Роли максимально надежны и протестированы в том числе на molecule. И чтобы создать конечный ресурс, нужно до 20 ролей объединить. Т.е. пользователь созданный в linux_user должен уйти на вход роли linux_group, а login/password там динамические. Эту "динамику" и проброс настроек нужно где-то собирать, в ABP такого нет, а тем более нет в Jenkins. A-service как раз нужен, чтобы соединить все сценарии ролей. Скорее всего, у вас нет динамического контента, либо идет хардкод и всё между собой связано, а это нарушение основного требования - гибкости.
По Jenkins. У нас он используется, чтобы собрать из A-services полную инфраструктуру. Там тоже есть чем поделиться, думаю еще в одной статье расскажу.
По поводу тестирования. Тестировать A-service достаточно легко, там жестко всё задано, понятные входные и выходные данные. Если бы A-service == role то было бы тоже легко тестировать, но любые изменения, к примеру смена логики создания пользователя или изменение версии OS, потребовала бы изменить все role.
Иерархия каталогов приложения мало связана с FHS, не совсем понял отсылку к FHS. В рамках Ansible best practis не нашел подходящей структуры, здесь нет inventory, roles и collections, они стоят ниже по архитектуре приложения.
A-service это playbook c набором конфигураций и ansible roles/collections. Т.е. в одном A-service может быть несколько ролей и коллекций, И, даже они могут быть разных версий.
Я специально акцентировал "проблему" с версионированием, это довольно интересный раздел достойный отдельной статьи. В ближайшее время поделюсь как мы проблему развернули в свою пользу.
Спасибо за вопросы. Понял о чём вы спрашиваете. Мы тоже работаем в направлении инвентаризации инфраструктуры и построении CMDB, но это мало связано c этой серией статей.
В статье больше о возможностях Ansible для описания инфраструктуры, где мы не используем другие модели.
По поводу UI, она в разработке. Пока не могу про неё рассказать.
Draw.io
Большой коммент) попробую не запутаться.
По Inventory. Он лежит в отдельном контейнере полностью соответствует ABP. Здесь описывал архитектуру - https://habr.com/ru/companies/pt/articles/896652/. Подключается по WebDAV в каждый А-сервис. Это помогает запустить любое количество Inventory и любых версий. Доработку Inventory можно делать независимо, а это сильно сокращается трудозатраты. (У нас еще разрабатывается UI, в котором графически можно нарисовать сложную структуру офиса и она конвертируется в inventory.yml). Это я всё к тому, если Inventory статичен, не дорабатывается, интеграция внутри и наружу минимальная, то такая архитектура с выносом в отдельный контейнер кажется избыточна, но у нас не так.
По ролям. У нас их больше 300. A-service около 150. Что такое роль у нас? Это, конечный сценарий выполняющие унарную конфигурацию. К примеру: роль - linux_user (создание пользователя, удаление, модификация), роль - linux_group (создание группы, удаление, добавление пользователей). Роли максимально надежны и протестированы в том числе на molecule. И чтобы создать конечный ресурс, нужно до 20 ролей объединить. Т.е. пользователь созданный в linux_user должен уйти на вход роли linux_group, а login/password там динамические. Эту "динамику" и проброс настроек нужно где-то собирать, в ABP такого нет, а тем более нет в Jenkins. A-service как раз нужен, чтобы соединить все сценарии ролей. Скорее всего, у вас нет динамического контента, либо идет хардкод и всё между собой связано, а это нарушение основного требования - гибкости.
По Jenkins. У нас он используется, чтобы собрать из A-services полную инфраструктуру. Там тоже есть чем поделиться, думаю еще в одной статье расскажу.
По поводу тестирования. Тестировать A-service достаточно легко, там жестко всё задано, понятные входные и выходные данные. Если бы A-service == role то было бы тоже легко тестировать, но любые изменения, к примеру смена логики создания пользователя или изменение версии OS, потребовала бы изменить все role.
Иерархия каталогов приложения мало связана с FHS, не совсем понял отсылку к FHS. В рамках Ansible best practis не нашел подходящей структуры, здесь нет inventory, roles и collections, они стоят ниже по архитектуре приложения.
A-service это playbook c набором конфигураций и ansible roles/collections. Т.е. в одном A-service может быть несколько ролей и коллекций, И, даже они могут быть разных версий.
Я специально акцентировал "проблему" с версионированием, это довольно интересный раздел достойный отдельной статьи. В ближайшее время поделюсь как мы проблему развернули в свою пользу.
Спасибо за вопросы. Понял о чём вы спрашиваете. Мы тоже работаем в направлении инвентаризации инфраструктуры и построении CMDB, но это мало связано c этой серией статей.
В статье больше о возможностях Ansible для описания инфраструктуры, где мы не используем другие модели.
По поводу UI, она в разработке. Пока не могу про неё рассказать.