Меня зовут Семен Трошкин, я работаю в крупной международной компании. У нас больше 10 серверов и около 200 информационных баз разного размера – есть как тестовые, так и рабочие среды. Мы часто используем на проектах Linux и PostgreSQL в качестве СУБД.
Всем этим нужно управлять. Мы долго искали для себя определенное решение и выбрали Ansible.
В докладе я расскажу об опыте использования Ansible в мире 1С: как мы его используем, и как он нам помогает.
О теме доклада
Расскажу, как зародилась тема доклада – когда мы начали использовать Ansible в продакшене, я стал интересоваться, как люди используют Ansible в своей работе.
На конференции Infostart Event 2019 года я пообщался об этом со многими специалистами – с Антоном Дорошкевичем, с Олегом Филипповым, и выяснил, что многие компании считают нецелесообразным применять Ansible, не видят в этом выгоды или боятся этого инструмента.
Поэтому цель доклада – объяснить, что Ansible можно использовать, это хороший и простой инструмент, который очень полезен и удобен в работе.
Ansible позволяет управлять любыми серверами, в том числе, на Windows. Эта тема очень большая – всю я ее не раскрою. Моя цель – познакомить людей с Ansible, чтобы им захотелось попробовать этот инструмент.
Для более подробного изучения этой темы рекомендую ссылку на видеоучебник по Ansible и на статьи по использованию Ansible для 1С на Инфостарте – «Установка 1С используя Ansible» и «Ansible роли для 1С».
Скрипты плейбука, о котором я буду рассказывать, приведены в моем репозитории на GitHub – вы можете развернуть себе эту систему через Vagrantfile и попробовать поиграться с Ansible.
Что такое системы управления конфигурациями
При работе с системами в Linux мы всегда настраиваем файлы конфигураций, устанавливаем пакеты и т.д. Есть множество систем, которые позволяют это делать автоматически.
Предположим, у вас в штате был крутой Linux-администратор, но он уходит: у вас возникает вопрос, какие параметры ядра он выставлял, какие пакеты устанавливал, каких версий. У вас возникает куча вопросов.
В первый момент кажется, что все эти моменты нужно зафиксировать в инструкции. Но зачем это все делать, если с помощью систем управления конфигурациями можно автоматически разворачивать все конфигурации серверов, настраивать пакеты, управлять конфигурационными файлами.
Допустим, у вас на Linux есть веб-сервер – Nginx или Apache. С помощью систем управления конфигурациями можно все настроить и установить.
Системы управления конфигурациями – это Puppet, Chef, SaltStack и Ansible.
Наш выбор – Ansible
Почему мы выбрали Ansible для управления конфигурациями:
-
Низкий порог вхождения. Все, что я покажу – это действительно просто.
-
Отсутствие агентов. У большинства вышеперечисленных систем, чтобы управление конфигурациями работало, на клиентскую часть нужно устанавливать специальное приложение – агента. Чтобы работал Ansible, специальные приложения на клиентскую часть устанавливать не нужно. Можно через SSH подключаться к компьютеру и управлять им. Это одна из причин, по которой мы выбрали Ansible.
-
Продукт хорошо документирован. Вы можете в Яндексе или в Google ввести «Ansible + [Название команды, которую хотите использовать]», в первой же строке результатов будет ссылка на справку, где все хорошо описано и будет понятно, как это все использовать.
-
Идемпотентность. Когда при многократном запуске скрипта (т.н. плейбука), все настройки серверов, Ansible приводит в соответствие всему, что было в вашем скрипте. Даже если настройки сервера были изменены, они приходят в нужное состояние.
-
Есть много готовых ролей, которые позволяют вам выполнять разные операции. Например, вам нужно настроить Nginx – на GitHub много готовых ролей, которыми вы можете воспользоваться и упростить свое администрирование или сопровождение. В нашем случае, когда мы выстраивали кластер PostgreSQL, у нас не было опыта в настройке Consul. Но мы нашли готовую роль по Consul – она ставится и на Windows, и на Linux-сервера. С помощью готовых ролей мы прекрасно разобрались с данным продуктом.
-
Есть поддержка Windows. В частности, мы использовали Ansible при установке Consul на Windows-сервера. Для этого используется сервис WinRM. Конечно, к WinRM могут быть вопросы от службы безопасности, но если служба безопасности вам это позволяет, вы можете развертывать системы, в том числе, и на Windows – там все для этого есть.
Мы в нашей работе с удовольствием используем Ansible, используем файлы, которые называются плейбуки, роли. Все это мы храним в репозитории для работы с серверами. Там у нас есть плейбуки:
-
для настройки и установки PostgreSQL под определенную ОС;
-
есть плейбук для установки Zabbix-агентов на все сервера, которые мы настраиваем – если у вас большое количество серверов на Linux, можно Zabbix-агентов спокойно через Ansible ставить, мы так и делаем;
-
конфигурацией и скриптами для Zabbix мы тоже управляем с помощью Ansible.
Плейбук – это простой скрипт на yaml, с которого начинается развертывание инфраструктуры серверов. Изменения в плейбуки могут вносить администраторы репозитория – допустим, нужно открыть порт и т.д.
Плейбук запускается на хостовой машине, где вы содержите репозиторий. Поэтому на той машине, с которой это все устанавливается, ставим Ansible.
Как настраивается среда
При установке есть ограничение – Ansible ставится только на Linux или MacOS.
Так мы – 1С-ники, и мне часто в работе нужно использовать Windows, у меня на Windows-машине стоит виртуальная машина с 7-ой CentOS с визуальным интерфейсом.
-
Для установки Ansible в CentOS нужно запустить
yum install ansible -
Второй этап – в файле-инвентори мы описываем настройки подключения к серверам, которыми хотим управлять.
-
Дальше создаем плейбук. Файл плейбука мы называем в соответствии с теми приложениями, которые мы разворачиваем – например, playbook_cluster.yml.
В плейбук может входить много ролей – одна будет настраивать Zabbix, другая – операционную систему, третья – устанавливать PostgreSQL. Группировки плейбуков вы определяете сами, как вам удобнее настраивать. Нам, например, настройки PostgreSQL-серверов определенного контура удобно держать в одном плейбуке. Потому что когда мы этот плейбук запускаем, мы четко понимаем, что все эти настройки выполнены.
Если надо открыть порт для бэкапов, я добавляю в плейбук строчку с портом, и все применяется. -
Проверяем подключение к хосту сервера – командой
ansible host1 -m ping
проверяем, что хост у нас подключен. Можно подключаться через RSA-ключ, который устанавливается на подключаемой машине, можно по паролю. Вариантов много, и это все подробно описано в документации. -
После того, как мы проверили подключение, мы можем запустить плейбук, и сервер настроится в нужное состояние.
Сразу настройтесь на то, чтобы использовать роли.
Роли хороши тем, что они объединяют настройки Nginx и ОС и так далее… Нужно сразу настраиваться на их использование.
Одна из наших ошибок при знакомстве с Ansible в том, что мы записывали все в плейбук и не использовали роли. Потом нам пришлось все переносить в роли.
Ansible – это просто
На слайде показаны примеры yaml-скриптов из плейбука.
Например, если нам нужно включить в CentOS репозиторий EPEL, мы в самом Linux выполним команду
yum install epel-release
В Ansible мы вместо этого выполняем вот этот вот скрипт справа. Выполнится то же самое – это одинаковые действия. Но в случае с Ansible, нам достаточно это один раз написать, а потом просто вызывать повторно. Если структура скрипта сложная – много связанных действий, можно поставить комментарий, чтобы не запутаться.
Для настройки ОС у нас есть отдельная роль – там описаны все пакеты, настройки и т.д. После этого мы вообще никогда не паримся, что у нас какой-нибудь необходимый пакет не установлен либо какие-то другие утилиты, которыми нам удобно пользоваться.
Или, например, вам при настройке Linux нужно открыть порты. Второй пример на слайде с именем «Enable port for consul firewalld 5433» показывает, как открыть порт. Не нужно запоминать длинную команду и вводить ее вручную, достаточно один раз прописать открытие порта в Ansible, и порт будет открыт.
Здесь мы централизованно храним все в одном месте, а еще используем Git, поэтому имеем историю версий.
Третий пример на слайде – скрипт с именем «ansible create directory». Здесь мы видим создание директорий – под каким пользователем она будет создана, и т.д. Если директория будет удалена, и мы запустим плейбук заново, она снова создастся с такими же правами и настройками.
Для запуска плейбука на основной машине, с которой вы управляете, нужно вызвать команду
ansible-playbook playbook_os.yml -l pgsrv01
Здесь pgsrv01 – это имя сервера, на котором мы хотим это установить. Если не указывать конкретный сервер, Ansible пройдется по всем доступным хостам и проверит, установлены ли все пакеты.
В чем заключается идемпотентность? Если пакет установлен, он его не будет заново переустанавливать. Мы можем перезапускать плейбук много раз, но состояние системы не изменится. Если мы установили PostgreSQL и запускаем опять этот же плейбук с установкой PostgreSQL, заново устанавливаться ничего не будет, Ansible это увидит.
На слайде показано, где задается описание всей этой инфраструктуры. Оно задается в файле-инвентори hosts.
Здесь мы видим группу PostgreSQL. В нее входят настройки для хостов pgsrv01 и pgsrv02, где задается ip-адрес, порт и ключ подключения.
Дальше видим группу ConsulOne и настройки для хоста consul.
Конкретно эти настройки хостов актуальны для работы хостов на VirtualBox, когда для каждой виртуальной машины на локальной машине пробрасывается порт, на котором слушается SSH. Вы видите, что все виртуальные запущены на локалхосте (127.0.0.1).
Vagrantfile, с помощью которого можно развернуть эти хосты, я выложил на GitHub – вы сможете его скачать и все это попробовать.
Как видите, мы можем серверы группировать в разные группы, описывать там подключения по-разному. Мы можем описать всю свою инфраструктуру, а потом в плейбуке в поле hosts ввести не all, а PostgreSQL (применять на всю группу PostgreSQL). Либо вместо all указать, что эти скрипты должны примениться на конкретном сервере – pgsrv02.
Демонстрация работы с ролями
Файл playbook_postgres1c.yml – это плейбук по настройке кластера Postgres.
Здесь на хосте consul_srv под администратором (become: true включает режим администратора) применяется роль os, которая настраивает ОС по умолчанию.
Далее мы видим, что на хостах, входящих в группу PostgreSQL, будут применены роли – os, postgres1c и patroni.
Хосты, входящие в группу PostgreSQL, указаны в файле hosts – соответственно, роли будут применены на серверах pgsrv01 и pgsrv02.
Настройки ролей находятся в папке roles – здесь есть папки consul, maintenance_postgresql, os, patroni и postgres1c.
Заходим в папку roles/os/tasks/ и открываем файл main.yml.
Здесь мы видим строки:
include_tasks: redhat.yml
when: ansible_os_family != 'Windows'
Это значит, что когда вы в плейбуке playbook_postgres1c.yml доходите до применения конкретной роли, выполнение переходит в скрипт main.yml, который находится в папке роли. И здесь, если не Windows, то происходит переход в скрипт redhat.yml.
В скрипте redhat.yml мы видим, что он:
-
устанавливает таймзону;
-
выключает selinux, если он вам не нужен;
-
устанавливает EPEL-репозиторий;
-
после этого ставит всякие пакеты – vim, htop, atop, lsof, rsync, если это нужно;
-
далее он проверяет, чтобы процесс firewalld был запущен и включен в автозагрузку;
-
то же самое – для процесса chronyd, который запускает синхронизацию системного времени по сети.
Если указанные процессы не стартуют, то при нажатии
ansible-playbook [НазваниеПлейбука]
будет показан подробный отчет, в котором вы можете какие-то ошибки игнорировать, а в какие-то – провалиться.
В зависимости от вашего описания, вы в этом отчете можете те или иные процессы перенастроить. Зашли в плейбук, перенастроили – запустили опять.
Далее мы можем посмотреть, как происходит установка postgres1c – для этого заходим в папку tasks.
Мы видим, что он сначала открывает необходимые нам порты.
Потом делает установку локали.
Далее командой copy мы копируем дистрибутивы – ходим по циклу, берем эти файлы 1С-ных сборок PostgreSQL и устанавливаем их по пути, указанном в поле dest.
Далее – устанавливаем нужные пакеты.
Устанавливаем PostgreSQL из дистрибутивов и создаем нужные директории для баз BUH и ZUP.
В папке handlers хранятся хэндлеры – это специальные задачи, которые вызываются из других задач ключевым словом notify. Например, здесь мы можем создать служебную задачу для рестарта какой-то службы и т.д., и потом вызвать ее из файла main.yml папки tasks этой роли.
Подытожу – какие элементы управления используются в Ansible:
-
В файле hosts – описание инфраструктуры.
-
Плейбуки с названиями – чтобы запустить те или иные процедуры.
-
Функциональность скриптов у нас разбита на несколько ролей: consul, maintenance_postgresql, os, patroni и postgres1c.
-
В папке templates мы можем хранить файлы конфигураций. Если мне нужно что-то изменить – например, настройки pg_hba, я могу их здесь перенастроить, применить данный плейбук, и у меня настройки PostgreSQL поменяются.
Несколько подходов к работе с Ansible
Поскольку я, как и многие, изначально в Linux не разбирался, я общался с разными Linux-администраторами, которые используют Ansible и интересовался, как они его используют, в каких режимах. По результатам общения я выяснил, что есть несколько подходов к работе с Ansible:
-
Есть администраторы, которые один раз устанавливают операционную систему с приложениями и делают определенные настройки через Ansible, а дальше уже руками донастраивают и работают. И дальше уже для этого сервера playbook не запускают.
-
Мы используем другой подход: когда у нас возникает необходимость изменения конфигурации, например, добавить новый порт или установить новое приложение – мы добавляем в плейбук несколько строчек кода, применяем его, и у нас происходит настройка серверов.
-
И есть сисадмины, которые запускают плейбуки по расписанию – у них расписаны все параметры серверов, все настройки и т.д. И у них каждую ночь по расписанию применяются все плейбуки, которые они считают критичными и необходимыми. И если какой-то плейбук не применился, администратор понимает, что система работает некорректно.
Мы для себя выбрали стратегию использования – запускать Ansible при необходимости, когда нам нужно что-нибудь перенастроить, потому что у нас круг допущенных администраторов невелик. Мы для себя именно так решили.
А на больших продакшенах, когда администраторов много, то чтобы быть уверенным, что все серверы в полном порядке, всегда все настроено и настройки очень громоздкие – там сисадмины плейбуки по расписанию запускают.
Для тех, кто не хочет лезть на GitHub, я на слайде привел пример, как в Ansible выглядят скрипты установки в роли.
Выводы
Подведем итоги:
-
Ansible упрощает администрирование и позволяет понять, как был настроен сервер. Например, я настраивал сервис, прошло несколько лет, я забыл – я могу всегда вернуться и проверить, как я настраивал. Либо если человек, который настраивал, уволился – мы всегда можем увидеть, как это все было настроено, какие параметры ядра. И при использовании Ansible одно из самых главных правил – руки прочь от ручного администрирования сервера, все только через Ansible. Если что-то надо поменять – находим Ansible, меняем скрипты, запускаем плейбук и все работает.
-
Ansible прост и удобен. Это просто супер. После того, как мы перешли на использование Ansible, я в восторге. Потратьте какое-то время, чтобы познакомиться с нем, но это просто супер-система.
-
С точки зрения идемпотентности – при многократном применении одного скрипта не происходит изменения того, что было сделано для этого. Если папка была уже создана, она заново не создается.
-
По настройке системы в реальной работе. Например, у нас появляется новый сервер, мы его настраиваем с точки зрения железа – подключаем сертификаты, подключаем к Ansible, и все. И дальше все автоматически настраивается и работает. И больше мы к этому серверу руками не возвращаемся.
-
Также мы все храним в Git – это контроль версий, можно всегда посмотреть, что было изменено, что было сделано. Это очень удобно.
-
Не нужно устанавливать агентов на серверы, все рулится плейбуками и достаточно гибко в настройке.
Поэтому хочется сказать – используйте Ansible, это классная система, управляйте своими серверами и будьте довольны только от того, что у вас все будет по уму.
Вопросы
Те примеры, которые были на скриншотах, были про развертывание кластера PostgreSQL. А именно сервер 1С? Он у вас живет отдельно на Windows или все-таки есть какие-то плейбуки и для него тоже?
У нас аутсорсинговая компания, поэтому нам в нашей инфраструктуре приходится работать с клиентскими базами, где могут быть самые разные решения, в том числе содержащие COMОбъекты и т.д. И проекты иногда очень большие – там есть именитые компании, которые наотрез отказываются переписывать свои объекты. Поэтому чаще всего мы сервер 1С держим на Windows, сервер 1С на Linux для нас – это скорее тестовый вариант.
Сейчас в тех скриптах, которые я дал, у меня нет примеров развертывания сервера 1С. Но судя по командам – yum install … точно так же можно скопировать дистрибутивы. Делается это все достаточно быстро.
Пробовали ли вы управлять через Ansible компьютерами на Windows?
Да, конечно. Мы используем WinRM, через него Ansible управляет Consul, который стоит на серверах 1С, которые на Windows.
В готовом плейбуке, который я выложил, есть команды для Consul на Windows. Вы можете посмотреть примеры регистрации в реестре, win_stat и т.д. Поэтому все это можно использовать в том числе и на Windows.
Было проблемно пробивать эту возможность у нашей службы безопасности, потому что они не хотят включать WinRM. Но если для вас это не проблема – то да, процессами Windows тоже можно управлять через Ansible.
А если в процессе обработки происходят какие-то ошибки, как они обрабатываются системой?
Да, при возникновении ошибок, мы можем заложить в наших скриптах, как на них реагировать – останавливать плейбук или их игнорировать. Есть ошибки, на которых мы останавливаем применение плейбука, видим информацию, что у нас произошла ошибка. Там можно уточнять эту информацию параметрами детально, и разворачивать хоть до потрохов – какой скрипт по SSH был отправлен, и какие команды. В том числе есть возможность отладки.
Когда у тебя возникает ошибка при интерактивном запуске плейбука – это один момент. Но если плейбук запускается по расписанию, разворачивается сразу на несколько виртуалок и ошибка возникает где-то там – это другой момент. Здесь ты уже не увидишь детальной информации.
Для мониторинга результатов запуска процессов по расписанию есть платный инструмент Red Hat Ansible Tower, который позволяет этим более красиво управлять. Но в целом, можно завязаться на Zabbix, и получать всю информацию об ошибках через Zabbix.
Был ли вас опыт сборки релизов через Ansible?
Лично у меня такого опыта нет. Но если попробовать поиграться – конечно, все это возможно. Но я считаю, лучше для этого Jenkins использовать.
*************
Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "1С и Linux". Больше статей можно прочитать здесь.
Приглашаем всех 11-12 ноября принять участие в INFOSTART EVENT 2021 в Москве: event.infostart.ru/2021_msk/
