Кластер 1С без ручных кликов: скрипты, Ansible и Terraform

Группа серверов 1С разворачивается программно в три шага: тихая установка платформы на каждый узел (msiexec на Windows, установщик setup-full-*.run на Linux), запуск агента ragent как службы и сборка кластера командами rac через сервер администрирования RAS. Всё это укладывается в один скрипт PowerShell или bash, а для пяти и более машин — в плейбук Ansible.

Ручная установка через мастер нормально работает на одном сервере. На третьем узле начинаются расхождения: где-то другой диапазон портов, где-то служба запущена под другим пользователем, где-то забыли открыть 1560–1591. Скрипт убирает эти различия: каждая машина собирается одинаково, а повторный запуск ничего не ломает.

Что подготовить до развертывания кластера

Скрипт не исправит то, чего нет в инфраструктуре. До первого запуска проверьте пять вещей.

• 🖥️ Одинаковая версия платформы на всех узлах. В одном кластере все рабочие серверы должны работать на одном номере сборки, например 8.3.24.xxxx. Дистрибутив кладите в общую папку или хранилище артефактов.
• 🌐 Имена узлов. Кластер обращается к серверам по именам. Каждое имя должно разрешаться с каждого узла и с клиентских машин — через DNS или hosts.
• 🔓 Порты. Агент — 1540, менеджер кластера — 1541, рабочие процессы — диапазон 1560–1591 (задаётся в свойствах рабочего сервера), RAS — 1545.
• 👤 Сервисная учётная запись. На Windows обычно локальный или доменный пользователь USR1CV8 с правом «Вход в качестве службы». На Linux установщик создаёт пользователя usr1cv8 сам.
• 🗄️ СУБД и лицензии. Сервер PostgreSQL или MS SQL доступен с рабочих серверов. Серверная лицензия получена заранее: активацию программной лицензии обычно проходят отдельно, после развертывания.

Какой способ выбрать

Тихая установка сервера 1С на Windows через PowerShell

Дистрибутив windows64full содержит файл 1CEnterprise 8 (x86-64).msi и трансформации adminstallrelogon.mst и 1049.mst. Компоненты выбираются свойствами MSI: SERVER, SERVERCLIENT, DESIGNERALLCLIENTS, THINCLIENT, WEBSERVEREXT, CONFREPOSSERVER. Значение 1 — ставить, 0 — нет.

Агент удобнее регистрировать отдельной командой, а не галочкой установщика. Так вы полностью контролируете порты и каталог реестра кластера.

$ver   = "8.3.24.1691"
$distr = "\\fs01\distr\1c\$ver"
$bin   = "C:\Program Files\1cv8\$ver\bin"

# 1. Тихая установка: сервер, утилиты администрирования, без клиентов
$msiArgs = @(
  "/i", "`"$distr\1CEnterprise 8 (x86-64).msi`"", "/qn",
  "TRANSFORMS=adminstallrelogon.mst;1049.mst",
  "SERVER=1", "SERVERCLIENT=1", "DESIGNERALLCLIENTS=0",
  "THINCLIENT=0", "WEBSERVEREXT=0", "LANGUAGES=RU"
)
Start-Process msiexec.exe -ArgumentList $msiArgs -Wait -NoNewWindow

# 2. Служба агента с явными портами и каталогом srvinfo
$cred = Get-Credential ".\USR1CV8"
New-Item -ItemType Directory -Force -Path "D:\srvinfo" | Out-Null
New-Service -Name "1C:Enterprise 8.3 Server Agent" `
  -BinaryPathName "`"$bin\ragent.exe`" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d `"D:\srvinfo`"" `
  -Credential $cred -StartupType Automatic
Start-Service "1C:Enterprise 8.3 Server Agent"

# 3. Сервер администрирования RAS
New-Service -Name "1C:Enterprise 8.3 RAS" `
  -BinaryPathName "`"$bin\ras.exe`" cluster --service --port=1545 localhost:1540" `
  -StartupType Automatic
Start-Service "1C:Enterprise 8.3 RAS"

Пароль в Get-Credential вводится вручную. Для полностью автоматического запуска берите его из хранилища секретов, а не из текста скрипта.

Правила брандмауэра одной командой

New-NetFirewallRule -DisplayName "1C Server" -Direction Inbound -Protocol TCP `
  -LocalPort 1540,1541,1545,1560-1591 -Action Allow

Порт 1545 открывайте только для машин администраторов, а не для всей сети.

Установка на Linux и развертывание через Ansible

С версии 8.3.20 для Linux есть единый установщик setup-full-<версия>-x86_64.run. Он работает без диалогов в режиме --mode unattended, нужные компоненты перечисляются через --enable-components:

./setup-full-8.3.24.1691-x86_64.run --mode unattended \
  --enable-components server,server_admin,ru

Начиная с 8.3.21 в каталоге платформы лежит шаблонный юнит systemd. Его подключают и запускают так:

VER=8.3.24.1691
systemctl link /opt/1cv8/x86_64/$VER/srv1cv8-$VER@.service
systemctl enable --now srv1cv8-$VER@default
/opt/1cv8/x86_64/$VER/ras cluster --daemon --port=1545 localhost:1540

Точный список компонентов для вашей сборки выводит сам установщик с ключом --help.

Плейбук для смешанного парка

Ansible хорош тем, что одна роль описывает и Windows-, и Linux-узлы. Повторный прогон не переустанавливает платформу: проверка creates пропускает уже выполненный шаг.

- hosts: c1_linux
  become: true
  vars:
    ver: "8.3.24.1691"
  tasks:
    - name: Копируем установщик
      ansible.builtin.copy:
        src: "distr/setup-full-{{ ver }}-x86_64.run"
        dest: "/tmp/setup-full.run"
        mode: "0755"
    - name: Тихая установка сервера
      ansible.builtin.command:
        cmd: /tmp/setup-full.run --mode unattended --enable-components server,server_admin,ru
        creates: "/opt/1cv8/x86_64/{{ ver }}/ragent"
    - name: Подключаем юнит
      ansible.builtin.command:
        cmd: "systemctl link /opt/1cv8/x86_64/{{ ver }}/srv1cv8-{{ ver }}@.service"
        creates: "/etc/systemd/system/srv1cv8-{{ ver }}@.service"
    - name: Запускаем агент
      ansible.builtin.systemd:
        name: "srv1cv8-{{ ver }}@default"
        enabled: true
        state: started
        daemon_reload: true

- hosts: c1_windows
  tasks:
    - name: Тихая установка на Windows
      ansible.windows.win_package:
        path: '\\fs01\distr\1c\8.3.24.1691\1CEnterprise 8 (x86-64).msi'
        arguments: "TRANSFORMS=adminstallrelogon.mst;1049.mst SERVER=1 SERVERCLIENT=1 THINCLIENT=0"
        state: present

Службу агента на Windows-узлах создаёт модуль ansible.windows.win_service с теми же параметрами ragent, что в скрипте PowerShell выше.

Облачная группа серверов: Terraform и cloud-init

Terraform отвечает за машины, сети и правила доступа, но не за 1С. Установку он передаёт в cloud-init: при первой загрузке узел сам скачивает дистрибутив и выполняет тот же bash-скрипт.

resource "hcloud_server" "c1" {
  count       = 3
  name        = "srv1c-0${count.index + 1}"
  server_type = "cx33"
  image       = "ubuntu-24.04"
  location    = "fsn1"
  user_data   = templatefile("${path.module}/c1-init.sh.tpl", { ver = "8.3.24.1691" })
}

Сборку кластера в cloud-init не выносите. Узлы поднимаются в разное время, и рабочий сервер может попытаться зарегистрироваться раньше центрального. Регистрацию надёжнее запускать отдельным шагом, когда все машины ответили на порт 1540.

Сборка кластера: регистрация рабочих серверов через rac

Утилита rac подключается к RAS центрального сервера. Сначала узнайте идентификатор кластера:

rac srv1c-01:1545 cluster list

Свежий агент при первом запуске создаёт собственный кластер на порту 1541. На центральном узле это и есть рабочий кластер. На остальных узлах этот локальный кластер не нужен и занимает порт менеджера. Удалите его на каждом добавляемом сервере до регистрации:

rac srv1c-02:1545 cluster list            # узнаём UUID локального кластера
rac srv1c-02:1545 cluster remove --cluster=<uuid-локального>

Затем добавьте узел в основной кластер:

CL=$(rac srv1c-01:1545 cluster list | awk '/^cluster/{print $3; exit}')
rac srv1c-01:1545 server insert --cluster=$CL \
  --agent-host=srv1c-02 --agent-port=1540 \
  --port-range=1560:1591 --name="srv1c-02" --using=normal

Полный список параметров рабочего сервера — назначение функциональности, отказоустойчивость, лимиты памяти — выводит rac help server.

Проверка статуса группы

Сразу после регистрации проверьте, что кластер видит все узлы и что на них поднялись процессы:

rac srv1c-01:1545 server list  --cluster=$CL
rac srv1c-01:1545 process list --cluster=$CL

Если у рабочего сервера нет ни одного процесса, клиенты его не используют. Проверьте порты и разрешение имён: именно они ломаются чаще прочего.

Создание информационной базы и пост-установочные задачи

Базу на сервере СУБД создаёт тот же rac. Ключ --create-database создаёт и пустую базу в PostgreSQL:

rac srv1c-01:1545 infobase create --cluster=$CL \
  --create-database --name=buh --dbms=PostgreSQL \
  --db-server=pg01 --db-name=buh --db-user=postgres --db-pwd=... \
  --locale=ru --license-distribution=allow

Конфигурацию загружайте пакетным Конфигуратором: 1cv8 DESIGNER /S 'srv1c-01\buh' /LoadCfg buh.cf /UpdateDBCfg. Для уже заполненной базы из выгрузки используется /RestoreIB файл.dt.

После этого автоматизируйте остальное:

• 🔐 зарегистрируйте администратора кластера и, при необходимости, администратора агента;
• 📁 настройте каталог журналов logcfg.xml — технологический журнал нужен при первой же проблеме;
• ⏱️ добавьте задание мониторинга, которое раз в несколько минут вызывает rac process list и пишет результат в систему наблюдения;
• 🗂️ сохраните итоговые параметры (UUID кластера, список баз) в репозиторий инфраструктуры.

Автоматическое обновление кластера: копия, блокировка, апгрейд

Обновление — самая частая операция, ради которой скрипты окупаются. Порядок одинаков для конфигурации и платформы: копия → блокировка входа → обновление → проверка → снятие блокировки.

Резервная копия перед обновлением

Для крупной базы копию делает СУБД (pg_dump или задание MS SQL) — это быстрее и надёжнее выгрузки в .dt. Копию конфигурации отдельно сохраняет Конфигуратор:

1cv8 DESIGNER /S 'srv1c-01\buh' /N Admin /P ... /DumpCfg /backup/buh-$(date +%F).cf /Out dump.log

Блокировка сеансов и обновление конфигурации

Блокировка и завершение сеансов обрывают работу пользователей — запускайте обновление в согласованное окно, а не днём.

rac srv1c-01:1545 infobase update --cluster=$CL --infobase=$IB \
  --infobase-user=Admin --infobase-pwd=... \
  --sessions-deny=on --scheduled-jobs-deny=on --permission-code=UPD777 \
  --denied-message="Обновление программы"

# оставшиеся сеансы завершаем по списку из rac session list
1cv8 DESIGNER /S 'srv1c-01\buh' /N Admin /P ... /UC UPD777 \
  /UpdateCfg update.cfu /UpdateDBCfg /Out update.log

rac srv1c-01:1545 infobase update --cluster=$CL --infobase=$IB \
  --infobase-user=Admin --infobase-pwd=... \
  --sessions-deny=off --scheduled-jobs-deny=off

После каждого шага скрипт проверяет код возврата и файл /Out. Ошибка на /UpdateDBCfg — повод остановиться и не снимать блокировку.

Обновление платформы на всей группе

Платформу обновляют на всех серверах кластера в одно окно, потому что версии на узлах должны совпадать:

1. Заблокируйте вход во все базы кластера и дождитесь завершения сеансов.
2. Остановите службы агента на всех узлах — рабочих и центральном.
3. Установите новую версию тем же скриптом тихой установки. Старая остаётся рядом, её удобно держать для отката.
4. Переключите службу на новый ragent: на Windows — изменив путь в службе, на Linux — подключив юнит новой версии и отключив старый.
5. Запустите центральный сервер, затем рабочие, и проверьте rac server list.

Каталог srvinfo с реестром кластера при этом не трогайте: новая версия агента подхватывает его сама.

Развертывание 1С в CI/CD-пайплайне

Когда скрипты обновления готовы, их легко вызвать из GitLab CI, Jenkins или TeamCity. Типовой пайплайн для доработок конфигурации:

1. Разработчик помещает изменения в хранилище или Git.
2. Сборка сохраняет .cf или расширение .cfe как артефакт.
3. Тестовый этап разворачивает базу на стенде, загружает артефакт и прогоняет автотесты.
4. Этап выкладки запускает тот же сценарий «копия → блокировка → обновление», что и вручную, но по кнопке и с журналом.

Для этих шагов часто используют открытые инструменты экосистемы OneScript, прежде всего vanessa-runner: он оборачивает пакетный Конфигуратор и rac в готовые команды. Список команд выводит vrunner help.

Ошибки при программном развертывании и что с ними делать

Одна ошибка встречается без явного сообщения: скрипт отработал с кодом 0, а /UpdateDBCfg на деле не применился. Пакетный Конфигуратор не всегда возвращает ошибку через код выхода. Поэтому разбирайте текст файла /Out и ищите в нём фразы об ошибке или отказе в доступе, прежде чем снимать блокировку.