При разработке и сопровождении крупных информационных баз на платформе 1С:Предприятие программисты часто сталкиваются со следующей архитектурной схемой: сервер приложений 1С и СУБД (например, MS SQL Server) располагаются на одном мощном выделенном сервере (в нашей схеме — Сервер 1), а разработчики запускают Конфигуратор и ведут работу в сессиях на выделенном терминальном сервере (Сервер 2).
В такой распределенной среде классический запуск службы сервера 1С с ключом -debug часто не приносит желаемого результата: точки останова в серверных процедурах и функциях на терминальном сервере попросту не срабатывают, хотя локально на самом сервере приложений все функционирует отлично. Давайте детально проанализируем причины этой проблемы, разберем особенности сетевого взаимодействия механизмов отладки 1С и рассмотрим по шагам два надежных способа решения данной задачи.
Основная сложность настройки классической TCP/IP-отладки в многосерверной архитектуре заключается в неочевидном направлении сетевого трафика. Большинство системных администраторов ошибочно полагают, что Конфигуратор инициирует подключение к серверу 1С, и открывают порты только на сервере приложений. На самом деле при использовании протокола TCP/IP процесс происходит в обратном направлении:
1560–1591) и начинает ожидать входящих подключений, выступая в роли TCP-сервера.rphost), выполняющийся на Сервере 1, при выполнении серверного кода пытается самостоятельно инициировать исходящее соединение к Конфигуратору на терминальном сервере (Сервер 2) на этот зарезервированный порт.Если на терминальном сервере включен брандмауэр Windows (или любой другой сетевой экран), он по умолчанию блокирует все подобные входящие запросы. В итоге сервер приложений не может передать отладочную информацию в сессию Конфигуратора, и точки останова не срабатывают. Также отладка ломается, если Сервер 1 не может разрешить сетевое имя (DNS-имя) терминального Сервера 2 в правильный IP-адрес.
Начиная с версии платформы 1С:Предприятие 8.3.7, разработчики добавили современный механизм отладки по протоколу HTTP. Он полностью решает проблему обратных соединений, поскольку в данной схеме появляется промежуточное звено — выделенный локальный сервер отладки (приложение dbgs), запускаемый на стороне сервера 1С.
При HTTP-отладке и Конфигуратор на терминале, и рабочий процесс сервера 1С сами подключаются к серверу отладки dbgs на определенный порт. Терминальному серверу больше не требуются открытые входящие порты, что существенно повышает безопасность корпоративной сети.
Рассмотрим по шагам, как перевести систему на HTTP-отладку:
Шаг 1. Настройка службы сервера 1С на Сервере 1
Нам необходимо изменить параметры запуска службы Агента сервера 1С. Для этого откроем редактор реестра Windows на Сервере 1 и перейдем по следующему пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent...
Найдем параметр ImagePath и добавим в строку запуска ключи -debug -http. Полный путь должен выглядеть примерно следующим образом:
"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug -http
После изменения реестра обязательно перезапустим службу сервера 1С. При перезапуске на Сервере 1 автоматически запустится процесс отладочного сервера dbgs.exe, который по умолчанию начнет прослушивать порт 1550.
Шаг 2. Настройка брандмауэра на Сервере 1
На сервере приложений (Сервер 1) необходимо разрешить входящие подключения по протоколу TCP для порта 1550. Это можно сделать через стандартную панель брандмауэра Windows, создав новое правило для входящих подключений.
Шаг 3. Перевод Конфигуратора на HTTP-протокол на Терминальном сервере (Сервер 2)
Теперь настроим среду разработки. Запустим Конфигуратор на Сервере 2 и выполним следующие действия:
http://192.168.1.100:1550 (вместо IP-адреса можно использовать сетевое имя Сервера 1).После этого перезапустим Конфигуратор. Протокол HTTP готов к работе, и теперь серверные процедуры будут успешно отлаживаться.
Если по каким-то внутренним причинам инфраструктуры вы хотите остаться на старом протоколе TCP/IP, нам придется детально настроить сетевую доступность со стороны сервера 1С к терминалу.
Проанализируем шаги настройки классического протокола отладки:
Шаг 1. Открытие портов на Терминальном сервере (Сервер 2)
В брандмауэре Windows на терминальном сервере необходимо разрешить входящие TCP-подключения для диапазона портов отладки 1С. По умолчанию платформа использует диапазон 1560–1591. Нам нужно создать правило, разрешающее входящие подключения для этого диапазона портов для всех исполняемых файлов платформы 1С.
Шаг 2. Проверка разрешения сетевых имен (DNS/Hosts)
Сервер приложений 1С должен четко понимать, на какой IP-адрес отправлять отладочный трафик, ориентируясь на сетевое имя терминального сервера. Проверим это. Откроем командную строку на Сервере 1 и выполним команду проверки связи:
ping Имя_Сервера_2
Если команда возвращает неверный IP-адрес или сообщает, что узел не найден, нам необходимо исправить разрешение имен. Для этого откроем файл hosts на Сервере 1 (расположен по пути C:\Windows\System32\drivers\etc\hosts) и вручную пропишем соответствие IP-адреса и сетевого имени терминального сервера:
192.168.1.200 TerminalServer2
Шаг 3. Изменение диапазона портов отладки при их занятости
Иногда стандартный диапазон портов 1560–1591 оказывается полностью занят рабочими процессами самого сервера 1С или другими приложениями. В таком случае мы можем жестко переопределить порты отладки на терминальном сервере с помощью конфигурационного файла debugcfg.xml.
Создадим текстовый файл с именем debugcfg.xml и сохраним его в папку bin\conf установленной платформы 1С на Сервере 2 (например, в каталог C:\Program Files\1cv8\8.3.22.1709\bin\conf\). Наполним этот файл следующим содержимым:
<config xmlns="http://v8.1c.ru/v8/debugcfg">
<debugports range="1560:1591"/>
</config>
При необходимости мы можем расширить этот диапазон или указать любые другие свободные порты, предварительно открыв их в брандмауэре.
Даже при идеально настроенном сетевом окружении и открытых портах точки останова могут игнорироваться системой из-за локальных параметров сеанса отладки в самом Конфигураторе. Давайте проверим ключевые опции автоматического подключения предметов отладки.
Выполним следующие действия в Конфигураторе на терминальном сервере:
Если в вашей системе также используются технологии внешнего COM-соединения, и вам требуется проводить отладку процедур, вызываемых через COM-объекты, обязательно убедитесь, что на терминальном сервере в папке bin\conf присутствует конфигурационный файл comcntrcfg.xml с разрешением отладки:
<config xmlns="http://v8.1c.ru/v8/comcntrcfg">
<debugconfig debug="true" debuggerURL="tcp://localhost"/>
</config>
Применение одного из вышеописанных методов (в особенности современного протокола HTTP) гарантирует стабильную работу механизма отладки серверного кода 1С в терминальной среде, сохраняя нервы разработчикам и избавляя от необходимости переключаться между различными удаленными столами.