Кластер 1С
Здесь показаны подключение к кластеру, прямой доступ к его СУБД и администрирование через RAS. Для каждого размещения — схема и соответствующий файл проекта. Обозначения схем и формат файлов проекта описаны отдельно.
Работа через кластер
Конфигуратор, агент и клиент используют connection из v8project.local.yaml. Подключение к одному адресу кластера:
infobases:
origin:
# Srvr — адрес сервера и порт менеджера кластера
# Ref — имя информационной базы, зарегистрированной в кластере
connection: 'Srvr="srv:1541";Ref="demo";'
Для уже настроенного отказоустойчивого кластера — два адреса кластера:
infobases:
origin:
connection: 'Srvr="srv1:1541,srv2:1541";Ref="demo";'
Список адресов задаёт подключение; отказоустойчивость настраивается на стороне кластера.
В этих схемах платформа и исходники находятся на машине раннера. Выгруженные файлы, журналы утилит и отчёты тестов остаются на этой машине. Во всех примерах используется один v8project.yaml; меняется подключение в v8project.local.yaml рядом с ним.
Кластер на своей машине
Раннер, сервер 1С и PostgreSQL установлены на одной машине. База demo уже зарегистрирована в кластере.
v8project.yaml:
workPath: .build # журналы и временные файлы; можно удалить
format: DESIGNER # исходники в формате платформы
source-set:
- name: main # локальное имя набора
type: CONFIGURATION # основная конфигурация
path: src/cf # путь от каталога v8project.yaml
v8project.local.yaml:
infobases:
origin:
connection: "Srvr=localhost:1541;Ref=demo" # кластер на машине раннера
localhost:1541 — адрес менеджера кластера на этой машине. Если вы выбрали другой порт, укажите его в Srvr.
Кластер на другой машине, несколько rphost
Раннер подключается к серверу srv по сети. Менеджер кластера направляет сеанс в один из рабочих процессов rphost. Поэтому с машины раннера должны быть доступны и порт менеджера, и диапазон портов рабочих процессов.
v8project.local.yaml:
infobases:
origin:
connection: "Srvr=srv:1541;Ref=demo" # сервер приложений
Имя srv должно разрешаться с машины раннера. Файлы и журналы сервера по этому подключению недоступны. Агент Конфигуратора запускается на машине раннера; для подключения к уже запущенному агенту используется tools.designer_agent.attach.
Отказоустойчивый кластер на двух серверах
В одном кластере настроены два центральных сервера — srv1 и srv2. Раннер подключается к базе demo по двум адресам: если один сервер недоступен, остаётся второй вход в кластер. Рабочие процессы обращаются к общей СУБД.
v8project.local.yaml:
infobases:
origin:
connection: 'Srvr="srv1:1541,srv2:1541";Ref="demo";'
Оба имени должны разрешаться с машины раннера; доступны порты входа и рабочие порты обоих серверов. Кластер уже настроен на отказоустойчивую работу — строка подключения не задаёт уровень отказоустойчивости и резервирование сервисов. Подробнее — руководство администратора 1С, раздел 2.2.5.
Кластер запущен из консоли
Сервер 1С запускаете вы в окне терминала. Он работает под вашей учётной записью; каталог данных и журналов задаётся при запуске. Раннер подключается к нему так же, как к серверу, запущенному службой.
v8project.local.yaml:
infobases:
origin:
connection: "Srvr=localhost:1541;Ref=demo" # кластер запущен в вашей консоли
Запустите сервер перед командой раннера и оставьте консоль открытой до её завершения. Файл проекта не управляет запуском и остановкой кластера; чтобы его поднимал раннер, объявите кластер под управлением раннера.
Кластер под управлением раннера
Кластер нужен для разработки и тестов на своей машине Windows, а запускать сервер 1С руками не хочется. Раннер запускает его как приложение, а не службой, — ragent с rmngr и рабочими процессами rphost — командой cluster start и останавливает командой cluster stop. Каталог данных кластера раннер держит под localPath, порты агента, менеджера и диапазон рабочих процессов выбирает свободными и отдаёт ответ после того, как агент принял соединение. Кластер живёт между командами, пока его не остановит cluster stop. Данные базы хранит ваша СУБД или PostgreSQL, который поднимает раннер. На Linux и macOS раннер кластер не запускает: команда отказывает.
v8project.local.yaml:
infobases:
origin:
user: developer # пользователь базы
password: "ib-password"
cluster:
managed: # сервер 1С поднимает раннер
name: demo # имя базы в кластере, Ref=
dbms: # ваша СУБД для данных базы
kind: PostgreSQL
server: localhost
name: demo_data # физическое имя БД
user: dbadmin
password: "db-password"
locale: ru # Locale= для создания базы
Строка соединения не объявляется: адрес Srvr=127.0.0.1:<порт>;Ref=demo раннер знает сам, потому что сам выбрал порт, а называет его cluster status. Серверные компоненты берутся из той же установки платформы, что выбирают остальные команды.
v8-runner cluster start # сервер 1С на своей машине, ждёт готовности
v8-runner infobase create # база в этом кластере, данные в вашей СУБД
v8-runner push
v8-runner test
v8-runner cluster stop
В отличие от автономного сервера, базу кластера создают в работающем кластере, поэтому infobase create идёт после cluster start. Останавливает раннер только кластер, который запустил сам; кластер службы или вашей консоли на тех же портах он не трогает и называет в ответе.
Процессы кластера и ras слушают все интерфейсы машины, ключей ограничить их адресом нет, а администраторов у нового кластера нет: база без пользователей открывается без учётных данных. Закройте порты брандмауэром, если машина доступна из сети.
Порты кластера раннер закрепляет при первом запуске: реестр кластера их хранит. Если закреплённый порт занял чужой процесс — например, кластер второй рабочей копии, — cluster start сам переносит базу в новый реестр на других портах, как --new-regport, и называет в ответе прежний regport и того, кто занял порт. Адрес кластера живёт только в состоянии под localPath: берите его из ответа cluster status, v8project*.yaml раннер не правит. Пока кластер этой базы работает, автономный сервер над той же БД не поднимается: одну БД держит один сервер.
Кластеру нужна лицензия на этой машине. Без неё сервер запускается, но Конфигуратор и клиент получают отказ «На сервере 1С:Предприятия не найдена лицензия».
Пароль PostgreSQL виден в командной строке при создании и регистрации базы в кластере: у этих команд другого способа передать его нет.
PostgreSQL под управлением раннера
Если своей СУБД нет, её тоже поднимает раннер: PostgreSQL из сборки для 1С, без службы и без прав администратора. Он слушает только 127.0.0.1, вход защищён сгенерированным паролем, а адрес и путь к файлу пароля называет dbms status.
infobases:
origin:
user: developer # пользователь базы
password: "ib-password"
cluster:
managed:
name: demo
dbms:
managed: {} # PostgreSQL поднимает раннер
name: demo_data # физическое имя БД
locale: ru # Locale= для создания базы
tools:
postgres:
path: "C:/PostgreSQL-1C/17" # каталог сборки
v8-runner cluster start # PostgreSQL и сервер 1С, ждёт готовности
v8-runner infobase create
v8-runner push
v8-runner test
v8-runner cluster stop # сервер 1С и PostgreSQL
Если PostgreSQL поднят отдельно dbms start, cluster stop его не трогает. Кто и что останавливает — в таблице владения.
Данные такого PostgreSQL лежат под localPath/infobases/<база>/managed/ (по умолчанию .local/ рядом с v8project.yaml): удаление workPath их не трогает. Команды удаления данных у раннера нет.
Прямой доступ к СУБД через ibcmd
Утилита ibcmd открывает базу непосредственно в СУБД. Перед её использованием остановите серверные процессы кластера, обслуживающего эту базу. Завершения сеансов или блокировки входа недостаточно: применение инструментов автономного сервера к базе под работающим кластером может разрушить базу данных (60).
Для этого подключения добавляется секция dbms. В ней задаются тип и адрес СУБД, физическое имя базы и учётные данные пользователя СУБД. Имя dbms.name может отличаться от Ref; пользователь СУБД задаётся отдельно от пользователя 1С.
В этом режиме используется dbms. Строка connection сохранена для обычной работы через кластер, когда вы снова его запустите. Наличие секции dbms не останавливает и не запускает кластер автоматически.
На своей машине, кластер остановлен
PostgreSQL продолжает работать на машине раннера. Серверные процессы 1С остановлены по условиям прямого доступа.
Если кластер был запущен из консоли, завершите запущенные вами серверные процессы; схема и подключение к СУБД те же.
v8project.local.yaml:
infobases:
origin:
connection: "Srvr=localhost:1541;Ref=demo" # штатная работа через кластер
dbms: # прямое подключение к СУБД
kind: PostgreSQL # тип СУБД
server: "localhost port=5432" # локальная СУБД; порт доступен раннеру
name: demo_data # физическое имя БД, не Ref
user: dbadmin # пользователь СУБД
password: "db-password" # пароль пользователя СУБД
localhost port=5432 — локальный PostgreSQL; demo_data — физическая база, в которой хранятся данные информационной базы demo.
На другой машине, кластер остановлен
СУБД находится на сервере db. Раннер обращается к ней по сети по условиям прямого доступа.
v8project.local.yaml:
infobases:
origin:
connection: "Srvr=srv:1541;Ref=demo" # штатная работа через кластер
dbms: # прямое подключение к СУБД
kind: PostgreSQL # тип СУБД
server: "db port=5432" # сервер СУБД, доступный машине раннера
name: demo_data # физическое имя БД, не Ref
user: dbadmin # пользователь СУБД
password: "db-password" # пароль пользователя СУБД
Адрес db port=5432 должен быть доступен с машины раннера. Адрес srv:1541 относится к серверу 1С и используется при обычной работе через кластер.
Администрирование через RAS
RAS — сервер администрирования кластера. Утилита rac подключается к нему отдельно от соединения с информационной базой. Этот канал нужен для управления сеансами: просмотра, завершения, запрета и разрешения входа, в том числе перед монопольной операцией (56, 57).
В примерах показаны три учётные записи: пользователь базы, администратор кластера и администратор центрального сервера. Укажите те, которые требуются для ваших операций (59).
RAS на отдельной машине План
На машине admin.example уже работает RAS. Раннер обращается к нему утилитой rac, а Конфигуратор подключается к базе через сервер srv.
v8project.local.yaml:
infobases:
origin:
connection: "Srvr=srv:1541;Ref=demo" # адрес базы
user: developer # пользователь базы
password: "ib-password"
cluster:
ras: "admin.example:1545" # отдельная машина с RAS
user: clusteradmin # администратор кластера
password: "cluster-password"
agent:
user: serveradmin # администратор центрального сервера
password: "server-password"
Адрес cluster.ras задаёт готовый сервер администрирования. Запуск и остановка этого RAS из раннера недоступны. Консоль кластера может обращаться к тому же RAS для управления серверами, лицензиями и профилями безопасности.
RAS запускает раннер План
Если cluster.ras не задан, раннер запускает RAS на своей машине на время команды и завершает его вместе с ней. Для этого на машине раннера нужны ras и rac той же версии, что и кластер (54, 55).
v8project.local.yaml:
infobases:
origin:
connection: "Srvr=srv:1541;Ref=demo" # адрес базы
user: developer # пользователь базы
password: "ib-password"
cluster:
user: clusteradmin # администратор кластера
password: "cluster-password"
agent:
address: "srv:1540" # агент, к которому подключится RAS
user: serveradmin # администратор центрального сервера
password: "server-password"
cluster.agent.address — адрес агента центрального сервера, к которому подключается RAS. При стандартном адресе его можно опустить: хост берётся из Srvr, порт — 1540 (63). Запуск и завершение RAS не останавливают сам кластер.
При заданном cluster.ras используется готовый RAS. В обоих вариантах обмен с базой идёт по connection; недоступность RAS мешает операциям, которым нужен канал администрирования.
Состав операций и выбор утилит — на странице Компоненты.