Оптимизация разворачивания HA-контура DirectumRX

17 0

Disclaimer! Данная статья будет полезна администраторам средней руки, и любителям автоматизации. Так же прошу взять во внимание то, что решение описанное в статье поставляется как пример, использовать его можно только на свой страх и риск. Решение из данной статьи подходит только для Astra Linux Orel (ВАЖНО!)

Расскажу про далеко не новую, но крайне гибкий и полезный инструмент - Ansible. Которая поможет автоматизировать большой спектр работ, сводя ручную работу на 0.

Ansible — это программное решение для удаленного управления конфигурациями. Оно позволяет настраивать удаленные машины. Главное его отличие от других подобных систем в том, что Ansible использует существующую инфраструктуру SSH, в то время как другие (chef, puppet, и пр.) требуют установки специального PKI-окружения. Подробнее https://habr.com/ru/post/305400/

Представим, что у вас есть 1 сервер, туда необходимо установить систему Directum. Вроде бы не особо много работы: базу, кролика, Mongo поставить не долго, конфиг заполнить тоже не долго. Теперь представим что у вас есть 3 сервера, из них:

  • 1 Сервер приложений
  • 1 База данных
  • 1 Сервер с mongo/rabbitmq/ (опционально с отдельным еще ELK конечно)

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

Теперь представим, что у вас 6 серверов:

  • 2 Сервера приложений
  • 1 Сервер с БД (опционально в HA-системах советую 3(Мастер, Горячая стендли реплика и рид реплика)
  • 1 Сервер хранилища документов
  • 1 Сервер с Redis/RabbitMQ/MongoDB
  • 1 Сервер балансировки нагрузки

При данной схеме работа капельку осложняется и добавляется немного рутины. Да и риск человеческого фактора уже возрастает.

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

Ansible же поможет нам автоматизировать это дело и облегчит жизнь.

Предположим вам поступила задача: "обновить N-десяток серверов". Можно зайти по очереди на каждый сервер, ввести условный: apt-get update && apt-get upgrade, времени займет много, да еще и слишком уж это нудно все.

Но есть вариант пойти другим путем - использовать Ansible. Ниже я в качестве примера расскажу, как обновить 2 сервера не заходя на них даже. Для начала нам необходимо создать файл инвентаря со всеми необходимыми вам серверами и разделить их на группы.

Пример содержания файла hosts.txt (инвентаря в данном случае):

# 1-e плечо сервера приложений
[webapp1]
10.0.10.10

# 2-е плечо сервера приложений
[webapp2]
10.0.10.11
 
# Группа с названием WEB_APP в которой содержатся webapp1 и webapp2
[WEB_APP:children]
webapp1
webapp2

[all:vars]
# данные для подключения по SSH для ВСЕХ клиентов которые находятся в данном инвенторе
# можно использовать для каждого отдельно, но  в данном случае для примера так удобнее
ansible_connection='ssh'
ansible_ssh_port='22'
ansible_user='user'
ansible_ssh_pass='1Qwerty@'

Теперь имея такой файл, я могу крайне легко обновить 2 сервера, просто создав playbook:

1) nano playbook.yml

2) Вписываем туда:

---
- name: Update && Upgrade
  hosts: WEB_APP # указываем что данные действия будут выполнены только для группы WEB_APP
  become: yes # это эскалация прав доступа, если не указан метод и юзер по дефолту юзается sudo

  tasks: # таска, которая выполняется в рамках ПЛЕЯ, для вышеопределенных серверов
         # В данном случае для группы WEB_APP, 

  - name: Update and upgrade apt packages
    become: true 
    apt: # тут мы указываем что необходимо использовать модуль APT
      upgrade: yes # указываем что с модулем APT нам надо произвести Upgrade при возможности
      update_cache: yes # обновлять ли информацию о пакетах
      cache_valid_time: 86400
...

Теперь у нас есть файл инвентаря и файл с плейбуком, но надо же как-то объяснить туле откуда что брать 

Для это нам нужен файл ansible.cfg

1) nano ansible.cfg

2) Вписываем туда:

[defaults]
inventory               = ./hosts.txt # это указывает на то, что файл инвентаря лежит в одном каталоге непосредственно с ansible.cfg

Имея файлы ansible.cfg/hosts.txt/playbook.yml в одной директории мы можем просто запустить 

ansible-playbook playbook.yml

После этого сервера webapp1 и webapp2 будут обновлены если найдется обновления для пакетов, в случае неудачи выполнения ansible вернет вам результат выполнения с указанием того, что конкретно не получилось сделать. Крайне удобно, не правда ли? 

А теперь я хочу представить на общее обозрение свой плейбук, который позволит настроить только что развернутые, абсолютно голые сервера за ~ 33 минуты!

А конкретно это плейбук, для разворачивания полного контура системы директум. и всем необходимым для работы системы. Необходимо сделать только:

1) настроить на своем прокси сервере проксирование на сервер балансировки нагрузки;

2) убедиться что на всех развернутых серверах один логин/пароль и настроено SUDO без пароля (важно!);

3) заполнить файл hosts.txt по своему усмотрению;

4) $ ansible-playbook ClusterDeploy.yml;

Результат: На выходе получаем полностью работоспособную систему, осталось только активировать.

 

Советую ознакомиться с содержанием гита и документацией по Ansible. Вы сможете адаптировать данное решение под свои нужды, а так же это может послужить хорошим скачком по изучению чего-то нового.

Ссылка на гит-хаб:  https://github.com/paperdadfo/directum-cluster-playbook.git
Там указано больше технической информации. 

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

Пока комментариев нет.

Авторизуйтесь, чтобы написать комментарий