Меня зовут Айдар Сафин. В мире 1С я с 2002 года, начинал с версии 1С:7.7. Сейчас являюсь лидером проекта по импортозамещению 1С на Linux-инфраструктуре в Magnit Tech.
Тема моей статьи — автоматизация настройки сервера приложений 1С на Linux с использованием Ansible.Тем из вас, кто уже использует Ansible для установки 1С или решения других задач в работе с системой, будет особенно интересно.
Я расскажу, какие действия необходимо выполнить, чтобы получить полноценный сервер приложений 1С на Linux. Затем объясню, что такое Ansible и как с его помощью можно подготовить виртуальную машину и настроить тот самый сервер приложений 1С на Linux.
Далее я предоставлю ссылку на наш репозиторий на GitHub, где мы опубликовали свои доработки по Ansible для установки платформы 1С. Кратко пройдусь по основным ролям: установка платформы, настройка служб 1С, логирование и мониторинг. После этого расскажу, как подготовить WSL и использовать его для запуска Ansible при развертывании платформы.
В конце приведу небольшой пример модификации роли в плейбуке, чтобы у вас сложилось понимание, как это работает и как с этим взаимодействовать.
Необходимость автоматизации и структура каталогов сервера 1С на Linux
Для настройки полноценного и работоспособного сервера приложений 1С на Linux требуется выполнить множество действий. Мы приняли решение использовать плейбуки Ansible, чтобы автоматизировать этот процесс в промышленных масштабах.
В настоящее время с помощью Ansible автоматизированы не все этапы, а лишь наиболее трудоемкие и критически важные. Однако это не означает, что невозможно автоматизировать все целиком. Ниже я покажу структуру каталогов на нашем Linux-сервере — это важно для понимания, особенно если вы захотите использовать наши плейбуки.
В ходе работы мы выработали определенную схему: используем отдельный раздел, например диск sdb (в нашем случае — раздел sdb1 объемом 100 гигабайт), куда монтируем директорию `/var/1С`.
Внутри этой папки `/var/1С` мы создаем подкаталоги для каждого порта отдельно. Например, на одном сервере могут быть размещены две платформы 1С на разных портах. Соответственно, одна из них находится в папке `1540`, другая — в папке `2540`.
В каждой такой папке находятся логи, журнал регистрации (например, `reg_1541`), временные файлы и другие необходимые данные. Такая структура значительно упрощает администрирование, повышает прозрачность и удобство работы. Мы без труда можем перезапускать службы, проводить очистку, обновление или переустановку платформы. Именно поэтому мы закрепили такую структуру как стандарт.
Демонстрация результата работы Ansible
Прежде чем перейти к детальному описанию Ansible и принципам его работы, хочу показать вам конечный результат автоматизации.
Все сводится к тому, что после настройки мы запускаем команду, например: `ansible-playbook -i hosts side.yml`.
Нажимаем Enter — и на всех указанных хостах начинается выполнение плейбука. В результате мы получаем либо один настроенный сервер приложений 1С, либо, если указали 50 серверов — сразу 50 готовых и настроенных систем с запущенными службами и всеми необходимыми параметрами. Причем можно настроить как одну, так и несколько служб одновременно.
На этом примере процесс занял всего 2 минуты. Основное время ушло на копирование дистрибутива платформы на удаленный сервер. Если же файл дистрибутива заранее разместить на целевых серверах другим способом, то все выполнение сократится до нескольких секунд.
Раньше настройка 50 серверов 1С под Linux занимала дни ручного труда, а теперь с Ansible решается за считанные минуты. При этом в ходе выполнения мы видим подробную статистику и статусы каждого шага.
Например, если мы обновляем платформу, в логах может отображаться статус *changed* — это означает, что действие привело к изменениям (например, файл был скопирован или служба перезапущена). Если задача прошла без изменений, статус будет *ok*. Возможен и статус *failed* («фатал»), который не всегда означает критическую ошибку. Иногда он возникает в штатной ситуации — например, при попытке удалить старую версию платформы, которой уже нет на сервере. Такой сбой можно обработать с помощью исключения (*exception*).
Если задать игнорирование ошибки, плейбук продолжит выполнение, и установка завершится успешно. Вот такой результат мы получаем в итоге.
Ansible и его основные компоненты
Теперь давайте разберемся, что такое Ansible и как с его помощью подготовить виртуальную машину. У нас есть общая схема работы: есть плейбук, есть инвентарь, и есть целевые хосты.
Начнем с Ansible. Это программное обеспечение для автоматизации IT-инфраструктуры. Оно настраивается с помощью языка YAML и работает по протоколу SSH без необходимости установки агентов на целевых хостах. Это означает, что мы запускаем Ansible с управляющей машины, и он через SSH подключается к нужным серверам, выполняя на них задачи, описанные в плейбуке. При этом на самих хостах не требуется устанавливать дополнительное ПО.
Теперь о структуре. Основой является YAML-файл — например, `side.yml`. Это и есть плейбук, в котором описана последовательность действий.
У нас также есть файл инвентаря (hosts), где перечислены целевые хосты — те серверы, на которых нужно выполнить настройку. Можно указать один хост, а можно — десятки, например, 50. Кроме того, важную роль в Ansible играют *роли*. Роли — это логически завершенные блоки конфигурации, состоящие из задач (тасков), шаблонов, файлов и переменных. Например, могут быть роли `install_1C`, `install_deb_packages` (для установки пакетов, например, через dpkg) и другие.
Вы сами определяете структуру и логику ролей в зависимости от задач. Затем эти роли подключаются в плейбуке, и Ansible последовательно их выполняет на указанных хостах.
Репозиторий с доработками и используемые технологии (YAML, Jinja, Python, Shell)
Все наши доработки мы выложили в репозиторий на GitHub — это проект `magnit-tech`, репозиторий называется `magnit-ansible-linux-1c`. В нем содержится 12 ролей Ansible. Кратко расскажу, для чего они предназначены.
https://github.com/magnit-tech/magnit-ansible-linux-1c/tree/v1.0.0
GitHub показывает, что 90% кода написано на Python. На самом деле основной язык в этом проекте — YAML. Именно на нем создаются плейбуки и конфигурации для Ansible. Хотя сам Ansible написан на Python, нам не нужно писать код на нем — мы работаем только с YAML-файлами для описания инфраструктуры и задач.
Почему же тогда преобладает Python? Потому что в репозиторий мы добавили и вспомогательные скрипты, написанные на Python. Например, у нас есть скрипт `ZabbixExporter.py`, который собирает метрики с серверов 1С и передает их в систему мониторинга Zabbix. Также есть `1crestart.py` — он перезапускает службу 1С, очищает сессии и выполняет другие обслуживающие операции.
Кроме того, в репозитории есть скрипт для резервного копирования важных конфигурационных файлов Linux, который автоматически отправляет их в GitLab. Именно из-за этих Python-скриптов GitHub определяет основной язык как Python, хотя логика автоматизации построена на YAML.
Также в проекте активно используется шаблонизатор Jinja2 (расширение `.j2`). Например, у нас есть шаблон, который формирует unit-файл службы `srv1cv8.service`. На его основе, подставляя нужные параметры — порт, пользователя, путь к платформе — генерируется финальный конфиг службы, который размещается в нужной директории и запускается через systemd. Также есть шаблон `default.vrd.j2`, используемый для публикации баз данных 1С через веб-сервер Apache.
Кроме того, в проекте присутствуют bash-скрипты (shell), которые выполняют различные команды на уровне операционной системы.
В файле README содержится подробная инструкция по работе с нашим репозиторием — вы можете ознакомиться с ней самостоятельно. Сейчас я лишь кратко пройдусь по основным моментам.
Роли Ansible для установки платформы 1С
У нас есть несколько ролей, связанных с установкой платформы 1С — в общей сложности шесть. Первая из них — `install_deb_packages`. Что она делает? Эта роль устанавливает необходимые DEB-пакеты с удаленного хоста. Вы указываете нужные пакеты в определенной папке, и они автоматически устанавливаются на целевых серверах.
Например, это могут быть компоненты Python, библиотеки или другие зависимости, требуемые для работы 1С. Также с помощью этой роли можно подготовить окружение перед установкой самой платформы.
Далее — роль `first_setup`. В ней происходит самое важное: создание пользователя usr1cv8, группы `grp1cv8`, а также всех необходимых каталогов, которые я показывал ранее: `/var/1C`, подкаталогов для портов, папок для временных файлов (`temp`), журналов регистрации (`reg`) и других данных. Все это структурировано и создается автоматически.
Кроме того, в рамках этой роли копируются необходимые шрифты, обеспечивающие корректное отображение интерфейса и отчетов в 1С.
Роль `install_1C` отвечает за непосредственное копирование дистрибутива платформы — файла "setup-full-{{ onec_version_name }}-x86_64.run" — на удаленный сервер и его установку с нужными параметрами. В нашем случае устанавливаются компоненты: «Сервер», «Администратор сервера» и «Дополнительные функции администрирования».
После этого «устанавливается» роль `install_ras` (Remote Administration Server). Она создает и запускает службу RAS — сервер удаленного администрирования. С ее помощью осуществляется управление кластером серверов 1С.
Также в процессе задействуется роль `install_ragent`, которая формирует и активирует системные службы `ragent`, `rmngr`, `rphost`, `dbgs` и другие.
В результате мы получаем полностью настроенную и запущенную инфраструктуру сервера 1С — включая все необходимые службы и процессы.
Роли Ansible для работы с веб-сервером Apache
Роль `setup_apache` отвечает за установку и базовую настройку веб-сервера Apache.
Роль `restart_apache` — это вспомогательная служебная роль, которая используется для перезапуска Apache в нужный момент, например, после изменения конфигурации.
Что касается публикации баз 1С: как я уже упоминал, у нас есть шаблон `default.vrd.j2`. На его основе генерируется финальный файл конфигурации `default.vrd`, который размещается в соответствующей директории веб-сервера (например, `/etc/apache2/sites-available/`). Эта операция выполняется в роли publishing и позволяет автоматизировать публикацию информационных баз через Apache.
Роли Ansible для мониторинга и дополнительных задач
Скрипт `ZabbixExporter.py` собирает ключевые метрики с серверов 1С и передает их в систему мониторинга Zabbix. Мы автоматически размещаем этот скрипт на удаленных хостах — в нашем случае в директории `/opt/1cv8/scripts` — и добавляем задание в cron, которое запускает его каждые 30 секунд для актуального сбора данных.
Роль `install_JRE` отвечает за установку JRE и включение поддержки расширенной реструктуризации (реструктуризация v2) на Linux-серверах. Этот процесс также полностью автоматизирован.
Роль `versioning_linux_configs` предназначена для резервного копирования важных конфигурационных файлов системы, связанных с платформой 1С. Она добавляет в cron задание для запуска нашего скрипта `versioning_configs.py`, который регулярно архивирует указанные файлы и отправляет их в GitLab. При необходимости можно настроить бэкап любых других конфигураций, просто дополнив список нужных расширений или путей.
Таким образом, помимо базовой настройки серверов, мы автоматизируем процессы мониторинга, обновления окружения и управления конфигурациями.
Подготовка окружения: использование WSL для запуска Ansible
Теперь о том, как запускать Ansible и какое окружение для этого лучше использовать.
Ansible написан на Python, поэтому его можно запускать даже с Windows — достаточно установить интерпретатор Python и необходимые зависимости. Однако, если наша цель — настройка Linux-серверов, гораздо удобнее работать из Linux-подобной среды. Это упрощает работу с SSH, файлами и правами, а также исключает возможные несовместимости.
Поэтому мы рекомендуем использовать WSL (Windows Subsystem for Linux). В нашем случае — это дистрибутив Debian.
Механика работы следующая: мы копируем содержимое нашего репозитория в WSL, например, в директорию `~/ansible`. Затем настраиваем конфигурационные файлы: указываем список хостов (в файле инвентаря), задаем пользователя, от имени которого будет выполняться подключение к удаленным серверам, и при необходимости корректируем другие параметры.
В репозитории помимо основного плейбука `side.yml` есть и дополнительные плейбуки для отдельных задач. Если вы используете `side.yml`, нужно проверить, какие роли в него включены. При необходимости вы можете закомментировать ненужные роли или изменить версию платформы 1С и другие параметры.
После настройки все готово к запуску. Выполняем команду, например: `ansible-playbook -i hosts side.yml`.
По умолчанию Ansible работает параллельно, обрабатывая несколько хостов одновременно. Вы можете управлять количеством потоков с помощью флага `-f`. Например, `-f 10` — до 10 параллельных соединений, а `-f 1` — выполнение в один поток, последовательно. Это бывает полезно при отладке.
Пример доработки роли Ansible: структура и параметризация
И в заключение — короткий пример доработки роли.
Возьмем, к примеру, роль `install_1C`. Она состоит из двух основных файлов: `tasks/main.yml` и `defaults/main.yml`.
В файле `defaults/main.yml` мы задаем параметры по умолчанию. Например, указываем путь к дистрибутиву платформы на локальной машине (в нашем случае — внутри WSL). Это та директория, где находится файл установки `setup-full-{{ onec_version_name }}-x86_64.run`.
Далее определяем, куда этот файл будет скопирован на удаленном сервере. Также здесь задается флаг `copy_inst: true`, который означает, что файл дистрибутива нужно скопировать с WSL на целевой хост. Если установить значение `false`, вы сможете заранее разместить дистрибутив на сервере другим способом — это сократит время выполнения плейбука.
В этом же файле указывается параметр `enable_components`, где перечисляются компоненты, которые необходимо установить. В нашем случае — «Сервер», «Администратор сервера» и «Дополнительные функции администрирования».
Также есть флаг `remove_old_services: true`. Он означает, что перед установкой новой версии платформы нужно удалить старую службу `server1с`. На практике это приводит к деактивации и отключению предыдущей службы перед запуском новой.
Переходим к файлу `tasks/main.yml`. Здесь описаны непосредственные действия. Первый блок — копирование файла установки. В поле `name` указано описание задачи: *«Copy file - install platform»*. Используется модуль `copy`, где задаются пути: `src` — откуда копируем (из WSL), `dest` — куда копируем (на удаленный сервер). Права на файл устанавливаются как `mode: 777`, чтобы обеспечить возможность запуска.
С точки зрения безопасности это допустимо, потому что после установки файл автоматически удаляется. Однако при необходимости вы можете изменить права доступа на более строгие.
Кроме того, этот шаг выполняется только при условии `when: copy_inst == true`. Если флаг включен, блок пропускается.
Второй блок — запуск установки. Команда выполняется с повышенными привилегиями (`become: true`, то есть от имени root). Указывается путь к скопированному файлу `setup-full-{{ onec_version_name }}-x86_64.run`, а также параметр `--mode unattended`, который включает автоматический режим установки без запросов.
Мы явно указываем, что не нужен клиентский компонент `client-full`, так как устанавливается только серверная часть. А компоненты для установки берутся из переменной `enable_components`, определенной ранее. Вы можете легко адаптировать и дорабатывать роли под свои задачи — меняя пути, состав компонентов, поведение скриптов и условия выполнения.
Таким образом Ansible превращает сложную и рутинную установку 1С на Linux в простой, быстрый и полностью автоматизированный процесс.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт