adm1c: веб-консоль сеансов 1С через RAC/RAS в Docker для техподдержки

adm1c - веб-консоль для просмотра и принудительного завершения сеансов 1С: в основе RAC, доступ к кластеру через RAS, поставка в Docker. Если вы администратор или ведущий специалист и хотите передать L1/L2 только операции по сеансам - без полной консоли кластера и без подбора версии толстого клиента администрирования на каждом рабочем месте, - ниже разбор связки «браузер, PHP, rac, RAS, сервер 1С» и настройки под эксплуатацию.

Зачем поддержке веб-консоль сеансов, а не штатная консоль администрирования?

Консоль администрирования кластера 1С умеет снимать зависшие сеансы, но открывает и удаление серверов, смену ролей, правки состава кластера. Для админов это нормальный рабочий инструмент; техподдержке я сознательно не даю такой радиус действия.

Отдельная проблема - версия платформы. Консоль должна совпадать с сервером, иначе список объектов кластера ведёт себя непредсказуемо.

На нескольких контурах быстро копятся установки 8.3.x с разными сборками, а у поддержки задача часто одна: посмотреть идентификатор сеанса и завершить сеанс.

adm1c оставляет в интерфейсе два действия: список сеансов выбранной информационной базы и завершение по идентификатору сеанс. Операции изменения состава кластера в РНР-слой не попадают - скрипты вызывают только узкий набор команд rac. Админы остаются у полной консоли, поддержка получает закладку в браузере.

Из конфигурации иногда предлагают «убить сеанс изнутри» через регламентные задания или БСП. Это другой контур: нужны права в базе, доработка конфигурации и политика блокировок. adm1c идёт административным путём через RAS, без установки толстого клиента на ПК оператора.

Как устроен adm1c: RAC, PHP, NGINX и Docker

Цепочка запроса линейная. Браузер обращается к NGINX; тот отдаёт статику и проксирует PHP-FPM. PHP собирает командную строку rac и читает stdout. rac подключается к хосту и порту службы RAS. RAS уже разговаривает с агентом сервера (ragent) и менеджером кластера.

Чтобы при форке не потерять rac и конфиги, бинарник платформы держу рядом с index.php, nginx.conf выношу в отдельный каталог. Ниже скелет типичной сборки adm1c.

Каталоги adm1c: NGINX, PHP, rac и docker-compose

На стороне 1С в голове держу два порта: CtrlPort агента (в примерах ниже 1540) и порт RAS (1545). rac в контейнере не должен стучаться в случайные порты rmngr, пока вы сами не разобрали топологию; для удалённого администрирования нормальный путь - RAS как прокси.

Один POST DBSELECT снаружи выглядит как обновление страницы, внутри уже вызов rac «сеанс list» через RAS. Три доверенные зоны здесь: NGINX, PHP и RAS.

Запрос списка сеансов через NGINX к PHP и rac

В образ PHP кладутся бинарники платформы с rac нужной сборки 8.3.x и пара скриптов, которые парсят вывод списка сеансов.

Завершение сеанса собирается как terminate или kill по сеанс id; формулировки подкоманд зависят от релиза 8.3, сверяйте с выводом rac help на той же сборке, что лежит в образе. Фронт - простой HTML и CSS без SPA: кнопки POST и скрытые поля SRV, CL, DB.

docker-compose поднимает два контейнера: NGINX (завершение TLS и basic auth, если включите) и PHP-FPM с rac. Исходники задуманы как форк под себя: правите index.php, стили, при необходимости добавляете логирование в файл или syslog.

ragent на сервере 1С держит CtrlPort и принимает команды управления кластером от локального менеджера; RAS сидит поверх ragent и даёт удалённую точку входа для rac. Поэтому в скрытом поле SRV указываете адрес, где слушает RAS, а не произвольный порт rmngr на другом хосте.

В Dockerfile PHP обычно копирую только bin/rac и зависимые библиотеки из дистрибутива платформы, без полного сервера 1С. Размер образа остаётся приемлемым, а смена rac сводится к замене каталога и пересборке образа.

Что править в index.php: кластер, сервер, база и формы

Идентификаторы кластера и информационной базы в rac - не имя в списке «1С:Предприятие», а uuid из вывода rac cluster list и rac infobase summary. Один раз снимаю их с машины админа, где уже стоит согласованная версия rac, и прошиваю в скрытые поля форм.

Команда rac cluster list localhost:1540 выполняется на сервере рядом с ragent; для удалённого контура тот же list через srv:1545 после поднятия RAS. Имя кластера в выводе помогает не перепутать контур, но в формах adm1c нужен uuid из колонки cluster.

Поле SU принимает только сеанс id из списка, не логин пользователя 1С. Поддержке проще регламент: скопировать uuid сеанса из таблицы, вставить в поле, нажать DEL сеанс; логин в журнале PHP дублирую для разбора спорных завершений.

Для каждой базы - свой блок: уникальные CL, DB, подпись на кнопке выбора и одинаковый SRV (имя или IP сервера, где слушает RAS). Если смешать DB двух баз в одном наборе скрытых полей, список сеансов будет чужим или rac вернёт ошибку про infobase.

Форма просмотра сеансов отправляет POST с DBSELECT; форма завершения принимает сеанс id в поле SU и шлёт USRSELECT. Ниже шаблон, который правлю под каждую базу (имена кнопок - на вкус команды).

<form method="POST">
<input name="DB" id="DB" value="uuid-инфобазы" type="hidden" readonly>
<input name="SRV" id="SRV" value="srv-1c.example.local" type="hidden" readonly>
<input name="CL" id="CL" value="uuid-кластера" type="hidden" readonly>
<input type="submit" name="DBSELECT" value="ERP прод" style="width:120px;height:25px"/>
</form>
<form method="POST">
<input name="SU" id="SU" value="" style="width:220px;height:25px" placeholder="session id">
<input name="SRV" id="SRV" value="srv-1c.example.local" type="hidden" readonly>
<input name="CL" id="CL" value="uuid-кластера" type="hidden" readonly>
<input type="submit" name="USRSELECT" value="DEL session" style="width:150px;height:25px"/>
</form>

На стороне PHP после DBSELECT вызываю rac «сеанс list» для пары cluster и infobase (точный синтаксис смотрите в справке rac для установленной 8.3). После USRSELECT - завершение по сеанс id без операций cluster update или infobase create.

Доменное имя в конфиге NGINX можно не трогать и заходить по IP хоста с контейнерами, если TLS и auth настроены на этот host. Перед docker compose build лучше заранее прописать server_name и пути к сертификатам, иначе cookie и редиректы будут вести себя нестабильно.

Как собрать docker-compose и увидеть первый список сеансов

После правок index.php и nginx.conf делаю docker compose build и поднимаю стек в фоне через docker compose up с детаснед-режимом на хосте, с которого RAS доступен по сети. Часто это тот же VLAN, что и сервер 1С.

Сначала с хоста проверяю telnet или nc на RASPort, затем открываю UI. Сеть Docker по умолчанию NAT; если RAS на другой машине, маршрут уже должен работать с хоста docker, не только из контейнера. rac проверяю через docker compose exec php bash, чтобы отделить проблему PHP от firewall на гипервизоре.

Порт 443 или 80 на NGINX привязываю к нужному интерфейсу, если на том же хосте несколько vhost. Для внутренней поддержки часто хватает HTTP за VPN, но пароли и сеанс id в формах всё равно не должны идти открытым текстом через корпоративный WiR09;Fi.

Внутри контейнера PHP проверьте, что rac в PATH и исполняемый: команда rac help без параметров должна печатать справку.

Первая успешная проверка в интерфейсе - кнопка базы и таблица сеансов с колонками user, app, сеанс, started (как отдаёт rac для той сборки, что в контейнере).

Если список пуст при живых пользователях, чаще всего неверный DB uuid или запрос ушёл не в тот кластер. Сверьте CL и DB с выводом rac на админской машине, а не с именем базы в консоли.

Логи смотрю в docker compose logs php и в ошибка log NGINX: там видно, если PHP не нашёл rac или shell_exec запрещён политикой образа.

Как поднять службу RAS на сервере 1С: порты, пользователь, скрипт

RAS ставят из той же линии платформы, что и сервер 1С в этом контуре. Путь к ras.exe на Windows - каталог bin установки, например C:\Program Files\1cv8\8.3.12.1567\bin\ras.exe.

После установки службы смотрю, что процесс слушает RASPort и что ragent на CtrlPort уже работает (служба агента кластера).

Пользователь службы - отдельная учётка с правом «Вход в систему как служба», без интерактивного входа. Пароль в скрипте создания службы - только пример; в проде задаю через LSA и не храню в репозитории.

@echo off
set SrvUserName=.\USR1C_RAS
set SrvUserPwd="ЗадайтеПароль"
set CtrlPort=1540
set AgentName=localhost
set RASPort=1545
set SrvcName="1C:Enterprise 8.3 Remote Server"
set BinPath="\"C:\Program Files\1cv8\8.3.12.1567\bin\ras.exe\" cluster --service --port=%RASPort% %AgentName%:%CtrlPort%"
set Desctiption="1C:Enterprise 8.3 Remote Server"
sc stop %SrvcName%
sc delete %SrvcName%
sc create %SrvcName% binPath= %BinPath% start= auto obj= %SrvUserName% password= %SrvUserPwd% displayname= %Desctiption%

На Линух-хосте 1С аналог - unit systemd или инит-скрипт с тем же смыслом: ras cluster --service --port=1545 localhost:1540, User= в unit, Restart=on-failure. Пути к ras лежат рядом с ragent в bin каталога платформы; версию binary сверяю с установленным srvrhost.

После sc start или systemctl start проверяю netstat или ss на RASPort и пробую rac «сеанс list» с любой машины, где установлен rac той же мажорной ветки, указав SRV и порт RAS.

RASPort выбираю в диапазоне, который уже зарезервирован для служб 1С на этом сервере, чтобы не пересечься с rphost или другими агентами. В документации к платформе есть рекомендации по портам; CtrlPort не трогаю без понимания, что агент кластера уже слушает новый адрес.

Если служба RAS падает сразу после start, смотрю Event Log Windows или journalctl: часто неверный путь к ras.exe, когда на сервере поставили новый релиз платформы, либо учётка службы без прав на каталог bin.

Что должно совпадать у RAC в Docker и RAS на сервере

rac в контейнере adm1c может отличаться мелкой сборкой 8.3 от ras.exe на сервере. В образе могла лежать 8.3.12.1567, а на сервере RAS обновили патчем - это не всегда ломает связку.

Критично другое: RAS и сервер 1С - одна линия платформы на этом хосте. Если RAS от 8.3.20, а ragent от 8.3.12, получите отказ соединения или обрыв протокола без понятного сообщения в UI.

Версию файлов в bin сверяю с версией установленного сервера в оснастке служб.

Несовпадение rac в контейнере с сервером проявляется реже, но когда платформу на контуре поднимают на новый релиз, пересобираю образ и подкладываю rac из свежего дистрибутива. Иначе парсер stdout в PHP может не найти поле сеанс в привычном формате.

Типовые команды, которые оставляю в PHP (без cluster insert и remove): получить список сеансов infobase; завершить сеанс по сеанс id. Пример ручной проверки с хоста, где установлен rac (подставьте свои uuid и порт RAS):

rac session list --cluster=<uuid-кластера> --infobase=<uuid-базы> srv-1c.example.local:1545
rac session terminate --cluster=<uuid-кластера> --infobase=<uuid-базы> --session=<session-id> srv-1c.example.local:1545

Если terminate мягко не срабатывает (зависший клиент), в справке rac для 8.3 может быть отдельная подкоманда принудительного завершения; смотрите rac session help и не давайте кнопку kill поддержке без регламента.

Как довести adm1c до прода: доступ, несколько баз, ошибки rac

Демо из коробки часто без auth на UI. В проде закрываю NGINX basic auth или ССО-прокси, включаю HTTPS, режу доступ по IP или VPN и пишу журнал: кто авторизовался, какой сеанс завершил, timestamp.

PHP может дописывать строку в файл рядом с логом NGINX. Для L2 оформляю регламент как замкнутый цикл без шага «открыть консоль кластера».

Цикл: выбор базы, сеанс id, terminate, запись в журнал

Несколько информационных баз - это несколько пар форм с разными DB и подписями кнопок, один CL на кластер, один SRV на endpoint RAS. Дублировать CL с разными DB нормально; дублировать DB с разными CL - только если база реально зарегистрирована в двух кластерах (редкий случай, проверяйте rac infobase summary).

Ошибка «неверный cluster id» почти всегда опечатка в CL или кластер переименовали после восстановления. «RAS недоступен» - firewall, не тот порт, служба RAS остановлена или SRV резолвится не туда из сети Docker (иногда нужен extra_hosts или IP вместо DNS).

Несовпадение версии RAS и сервера 1С лечится установкой RAS из того же дистрибутива, что и ragent. rac в контейнере при этом можно не трогать, пока парсинг списка сеансов не ломается.

Минимальный фрагмент NGINX для basic auth (файл паролей генерируете htpasswd отдельно):

location / {
    auth_basic "adm1c sessions";
    auth_basic_user_file /etc/nginx/htpasswd/adm1c;
    include fastcgi_params;
    fastcgi_pass adm1c-php:9000;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}

После внедрения прогоняю чек-лист: RAS слушает порт, rac «сеанс list» с хоста контейнера проходит, UI показывает сеанс тестового пользователя, завершение тестового сеанса пишется в журнал, лишние URL к PHP не открыты без auth.

Самопроверка перед передачей поддержке:

1. RAS той же версии платформы, что ragent на сервере 1С, порт RAS в диапазоне службы и доступен с хоста Docker.
2. В index.php для каждой базы свой DB uuid, CL совпадает с rac cluster list, SRV указывает на RAS, не на произвольный порт менеджера.
3. docker compose up поднимает NGINX и PHP, rac внутри контейнера исполняется, список сеансов совпадает с rac вручную.
4. На NGINX включены HTTPS, basic auth или аналог, ограничение по сети, лог завершений сеансов.
5. PHP вызывает только сеанс list и terminate или kill по сеанс id, без команд изменения кластера.

Подводный камень, который встречаю чаще остальных: поддержка путает имя базы в списке 1С и uuid infobase в скрытом поле. Пока не покажете кнопку с понятной подписью и не зафиксируете uuid в конфиге, ошибки будут повторяться не из-за Docker, а из-за идентификаторов.