Назад | Перейти на главную страницу

Подход Ansible для нескольких ролей приложений

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

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

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

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

Сейчас я рассматриваю следующее:

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

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

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

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

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

Я развертываю множество приложений на основе 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. Помните, что ансибл не гарантирует идемпотентности, как это пытается сделать марионетка, поэтому вам нужно быть осторожным.

- include: app_microservice.yml

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

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