Подход Ansible к множественным ролям приложений

Question

Немного предыстории: я работал с Puppet 3 года и довольно хорошо понял его архитектуру. Наша компания рефакторит весь наш продукт, основывая его архитектуру на микросервисах, и начинает использовать непрерывную интеграцию/развертывание. Я воспользовался этой возможностью, чтобы переключить наше управление конфигурацией на Ansible, чтобы я мог использовать только один инструмент и для развертывания, и для конфигурации/оркестровки.

Наша архитектура будет полностью основана на AWS, с Live, Staging и 3 Integration/QA средами. Каждый микросервис будет иметь свой собственный отдельный процесс развертывания, а Integration/QA envs будет содержать все приложения в одном экземпляре, в то время как Live/Staging будет иметь несколько экземпляров и в некоторых случаях разные пулы экземпляров для каждого микросервиса.

Моя цель — иметь единый «репозиторий» конфигурации/развертывания Ansible для всех сред, используя переменные для параметризации шаблонов через среды. Таким образом, мы будем знать, что у нас есть последовательный процесс конфигурации и развертывания на протяжении всего цикла разработки.

В чем я сейчас сомневаюсь, так это в том, как я подхожу к созданию ролей для этих множественных приложений. Я также нахожу эту тему довольно сложной для «гуглинга», поскольку большинство сообщений, которые я нахожу, представляют собой простые руководства или примеры развертывания одного приложения.

Сейчас я думаю о следующем:

1. Иметь отдельные роли для каждой нужной мне «службы», например nginx, java, logstash и т. д., с каждым файлом конфигурации приложения внутри. Таким образом я сохраняю повторное использование ролей и избегаю повторений, когда два или более приложений используют довольно похожий файл конфигурации, который можно сделать различным с помощью переменных. У меня также будет роль развертывания со всеми задачами развертывания в ней. Это подход, который я обычно использую при работе с Puppet, но он может разбрасывать конфигурацию, иногда делая «трудным» поиск и добавление пары случаев, когда изменение в конфигурации одного приложения может повлиять на другое (в основном из-за отдельных шаблонов, обслуживающих более одного приложения).

2. Иметь одну роль для микросервиса. С этим проще работать, так как все конфигурации и переменные находятся в одной роли, но мне придется повторять задачи и конфигурации для каждого микросервиса, и это меня немного коробит.

Причина этого вопроса в том, чтобы оценить, как люди, столкнувшиеся с той же проблемой, справляются с ней, поскольку найти разумные ответы на нее с помощью поиска Google, кажется, практически невозможно, а у меня нет друзей/знакомых, которые работают с Ansible/развертыванием нескольких приложений.

Извините, если я выразился недостаточно ясно/запутанно, и спасибо за каждую информацию, которую вы мне можете дать.

Answer 1

Я бы сделал так, чтобы у каждого были свои роли.системная службачто необходимо вашему приложению,игратьи арольдля каждого приложения/микросервиса игрупповые и/или хостовые переменныеиролевые переменные и значения по умолчаниюкоторые определяют, что делать.

Я развертываю много приложений на основе PHP, поэтому это выглядит примерно так:

Я поиграю app_microservice.yml:

---
- hosts: app_microservice_servers
  roles:
    - nginx
    - mariadb
    - php-fpm
    - app_microservice

Так что я возьмуроль roles/app_microserviceкоторый развертывает код. Когда я запускаю эту игру, сначала будут установлены и настроены необходимые компоненты nginx, mariadb и php-fpm, если они еще не были установлены.

В дополнение к вызову roles, игра может также запускаться произвольно tasks. Не стесняйтесь смешивать и сочетать их, если что-то настолько просто, что полная роль не требуется.

Эта игра также идет all.ymlвместе с любой другой игрой, так что я могу иногда делать ansible-playbook all.yml. Помните, что ansible не гарантирует идемпотентность, как пытается puppet, так что с этим нужно быть осторожным.

- include: app_microservice.yml

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

Например, я назначаю уникальный пароль root для MySQL каждому хосту, но у меня есть шифры и протоколы SSL, определенные таким образом group_vars/all/main.yml, что если их необходимо изменить, для них есть один источник истины.