Введение
Ввиду ограниченных штатных возможностей взаимодействия платформы 1С:Предприятие с другими системами, рабочие сервера на основе web-приложения OneScript, играют ключевую роль в выполнении задач, которые не могут быть выполнены средствами платформы.
Таким образом, целью настоящей статьи является знакомство с возможностями конфигурации АИТП (проект на GitHub), в части выполнения задач с использованием рабочих серверов OneScript.
Системные требования
Версия платформы не ниже 8.3.10.2252
Версия конфигурации не ниже 0.4.10.61
Рабочий сервер OneScript
Рабочий сервер OneScript – это кроссплатформенное web-приложение, созданное на основе каркасной конфигурации, и предназначенное для выполнения фрагментов кода или вызова методов в среде OneScript. Готовые к развртыванию файлы web-приложения расположены в макете РабочийСерверOneScriptWebПриложениеАИТП. С примером методики развертывания можно ознакомиться в этой статье.
Основные возможности
Рабочий сервер содержит два http-сервиса (runscript.os и callmethod.os), которые предоставляют API, позволяющее выполнять соответственно фрагменты кода (скрипты) OneScript, вызывать методы, а также осуществлять асинхронное выполнение фрагментов кода.
Сервер содержит в своем составе библиотеку, позволяющую взаимодействовать с устройствами по протоколу SSH и SCP, а также библиотеку для взаимодействия с СУБД. В настоящее время поддерживаются СУБД MS SQL Server, PostgreSQL, а также MySQL. Это позволяет серверу эффективно взаимодействовать с устройствами и СУБД напрямую, как из ОС Windows, так и из ОС Linux.
С целью повышения уровня доступности, а также балансировки нагрузки, возможно развертывание и использование ферм серверов. Пример такого развертывания описан в этой публикации.
Поскольку код сервера полностью открыт, Вы можете в любой момент добавить необходимый Вам функционал или изменить существующий.
Взаимодействие конфигурации с сервером
Как было указано выше, web-приложения рабочего сервера OneScript имеет два http-сервиса, посредством которых производится взаимодействие конфигурации и рабочего сервера.
Взаимодействие конфигурации с рабочим сервером происходит по протоколу http(s) и сводится к отправке POST-запросов с соответствующими параметрами, с последующим получением результатов выполнения скрипта или вызова метода.
При асинхронном выполнении скрипта, после получения запроса, сервер создает и запускает фоновое задание, в котором выполняется необходимый Вам фрагмент кода. Затем, возвращает данные, идентифицирующие фоновое задание, данные результатов выполнения, а также рабочий сервер, на котором выполняется задание. Последний пункт особенно важен в случае развертывания фермы серверов, так как запрос на выполнение кода осуществляется на url кластера, а проверка активности фонового задания, а также получение результатов его выполнения, должны осуществляться посредством выполнения запросов к конкретному экземпляру web-приложения (ноде кластера). В качестве идентификатора экземпляра сервиса (ноды кластера) используется содержимое файла serviceurl, которое используется для поиска необходимого сервиса.
Результаты выполнившихся фоновых заданий хранятся в виде файлов в папке JobResults, web-приложения. После получения информации о результатах выполнения, данная информация должна быть удалена явно, вызовом соответствующего метода.
Общие замечания
Функционал взаимодействия с рабочими серверами OneScript оформлен в виде набора подсистем:
OneScriptАИТП – содержит реализацию функционала взаимодействия с рабочими серверами OneScript.
МониторингДоступностиСервисовOneScriptАИТП – содержит реализацию функционала по мониторингу доступности рабочих серверов.
УдалениеРезультатовЗаданийСервисовOneScriptАИТП – содержит реализацию функционала по “сборки мусора” на рабочих серверах.
ПользовательскийИнтерфейсOneScriptАИТП – содержит настройки пользовательского интерфейса подсистемы (см. рис. 1.).
Рисунок 1. Пользовательский интерфейс подсистемы.
Общие настройки
Для использования рабочих серверов OneScript, необходимо настроить параметры взаимодействия с ними. Для хранения этих параметров, предназначен справочник Сервисы Onescript (см. рис. 2.).
Рисунок 2. Справочник Сервисы OneScript.
Каждый элемент справочника соответствует рабочему серверу (ноде) или ферме серверов, в случае использования кластера, и содержит настройки подключения к http-сервисам рабочего сервера/фермы.
Как можно увидеть, справочник имеет иерархическую структуру, где на верхнем уровне расположены одиночные рабочие сервера и фермы серверов. Рабочие сервера, входящие в состав ферм, рекомендуется включать как дочерние элементы соответствующего сервиса фермы.
Как правило, при использовании рабочих серверов OneScript, существует хотя-бы один сервер или ферма серверов. Для хранения настроек этой фермы используется константа Ферма серверов по умолчанию (см. рис. 3.).
Рисунок 3. Ферма серверов по умолчанию.
Если в параметрах методов не указана конкретная ферма/сервер, программный код будет обращаться к ферме серверов по умолчанию.
Работа из программного кода
Функции работы с сервисами OneScript расположены в общем модуле OneScriptАИТП.
ВыполнитьСкрипт – используется для выполнения фрагментов кода в синхронном и асинхронном режиме.
ЗаданиеАктивно – используется для проверки факта окончания асинхронного выполнения фрагмента кода.
ПолучитьРезультатВыполненияЗадания – используется для получения результата асинхронного выполнения фрагмента кода.
УдалитьРезультатВыполненияЗадания – используется для удаления результата асинхронного выполнения фрагмента кода. Как правило, вызывается сразу после получения результата выполнения.
УдалитьРезультатыВыполненияЗаданийСозданныхДоПериода – используется для удаления оставшихся результатов заданий, старше определенного периода.
Инструменты разработки
Для облегчения разработки процессов, в подсистему включены средства для интерактивной работы с СУБД (рис. 4.), а также консоль выполнения кода (рис. 5.), которые позволяют в интерактивном режиме выполнять запросы к СУБД, а также выполнять фрагменты кода OneScript.
Рисунок 4. Интерактивная работа с запросами к СУБД.
Ввиду того, что данное средство использует технологию COM компонентов, его использование возможно в случае, если сервер 1С:Предприятие, на котором размещена конфигурация АИТП, работает под управлением ОС Windows. Однако, данный факт не мешает выполнению запросов к СУБД на рабочем сервере OneScript в среде Linux.
Рисунок 5. Консоль выполнения кода.
Мониторинг доступности
Мониторинг доступности и работоспособности сервисов OneScript является важной задачей т.к. это напрямую влияет на возможность выполнения ваших прикладных процессов, если они используют рабочие сервера OneScript. Для мониторинга доступности сервисов OneScript, в конфигурации реализован механизм мониторинга состояния сервисов, который размещен в подсистеме МониторингДоступностиСервисовOneScriptАИТП.
Логика работы механизма проста:
Через определенные промежутки времени, определяемые настройками расписания соответствующего регламентного задания (Мониторинг доступности сервисов OneScript), на всех сервисах, сконфигурированных для мониторинга (см. рис. 6.), производится запуск тестового скрипта и/или вызов тестового метода. В случае обнаружения недоступности сервиса по каким-либо причинам, создается процесс мониторинга недоступного сервиса, логика работы которого, представлена на рис. 7.
Рисунок 6. Конфигурирование сервисов OneScript для мониторинга.
Рисунок 7. Схема процесса мониторинга недоступного сервиса.
“Сборка мусора”
В процессе эксплуатации могут возникать ситуации, когда из-за программных, сетевых или иных ошибок, удаления результатов асинхронного выполнения скриптов не происходит. Результатом этого факта является накопление “забытых” файлов результатов, на рабочем сервере, что в конечном счете может привести к проблемам с дисковым пространством.
Для борьбы с этим явлением, существует специальный механизм, реализованный в подсистеме УдалениеРезультатовЗаданийСервисовOneScriptАИТП.
Логика работы механизма, аналогична логике работы механизма мониторинга:
Через определенные промежутки времени, определяемые настройками расписания соответствующего регламентного задания (Удалить результаты заданий сервисов OneScript), производится попытка удаления файлов с результатами асинхронного выполнения скриптов, которые существуют более определенного периода времени. Попытка удаления предпринимается на всех сервисах, для которых произведены соответствующие настройки (см. рис 8.), причем для каждого сервера создается отдельное фоновое задание.
Рисунок 8. Настройки удаления результатов заданий.
В случае возникновения каких-либо проблем, для каждого проблемного сервиса создается процесс обработки ошибки. Логика работы процесса представлена на рис 9.
Рисунок 9. Схема процесса обработки ошибки удаления результатов заданий.
Для оперативного контроля, необходимо настроить адресацию задач и оповещения, по методике, описанной в этой статье.
Заключение
Надеюсь, что данная статья поможет Вам в использовании конфигурации АИТП, для автоматизации Ваших процессов.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
(0) OneScript набирает популярность. До сих пор удивляюсь, но раз сообщество использует, значит все не зря!
+
Примеры сугубо профессиональные с очень узкой нишей. Надо более массовое.
(2)Это пока что-то типа документации по развертыванию и краткое описание, чтоб можно было установить и попробовать.
Относительно примеров — я Вас услышал, попробую что-нибудь придумать
Правильно ли я понял: для создания «рабочего сервера onescript» нужно установить onescript, запустить 2 *.os скрипта http сервиса (которые будут обрабатывать запросы по shh или запросы к СУБД).
Самое непонятное для меня после первого прочтения: откуда http сервис берёт последовательно выполнения команд и шаблон результата: из os скриптов, подключается к каркасной конфигурации, мега составной http запрос, каркасная конфигурация должна ныть на каждом рабочем сервере?
Только после 3го прочтения статьи и других указанных материалов у меня появилось предположение, что схема последовательности действия (Рисунок 9) хранится ТОЛЬКО в каркасной конфигурации, которая и посылает следующую команду из последовательности на http сервисы «рабочих серверов onescript» сразу после получения результата выполнения предыдущей команды.
Рекомендую автору более подробно разложить процесс выполнения последовательности команд указанных в схеме процесса.
Еще мне не понятно:
— как запускать os скрипты http сервисов? Как их перезапускать при аварийной остановке процессов?
— как производится проверка легитимности вызова исполняемого кода при вызове через http сервис? Есть ли авторизация на http сервисе?
Не совсем так.
Конфигурация содержит общий макет РабочийСерверOneScriptWebПриложениеАИТП, который представляет собой zip-архив и содержит преднастроенное web-приложение OneScript (включая файлы платформы OneScript и библиотеки) на базе http-сервисов.
Развертывание рабочего сервера OneScript фактически сводится к публикации этого приложения на web-сервере Apache или IIS в операционных системах Linux или Windows.
.
Для публикации в IIS — создаете web-приложение, скажем в консоли IIS и копируете содержимое архива в папку web-приложения.
Да, именно так. АИТП — это конфигурация 1С (на сколько я понял — Вы назвали ее каркасной) с необходимыми модулями и библиотеками, где Вы создаете в конфигураторе обычный бизнес-процесс в соответствии с некоторыми соглашениями. В момент выполнения задач БП Вы пишете код, который может вызывать http-сервисы OneScript и получать результаты вызова. Фактически Вы отправляете http-запросы, затем получаете и обрабатываете результаты.
(4)
Если Вы подскажете как это получше объяснить и что изменить — я буду Вам безмерно благодарен.
Вызовом библиотечной функции OneScriptАИТП.ВыполнитьСкрипт
Пожалуйста, поясните подробнее, о каких процессах идет речь
Если не сложно — опишите поподробнее, что Вы имеете ввиду. В настоящее время работа с http-сервисами OneScript происходит также, как если-бы вы работали с web-сервером. Т.е. если обращающийся пользователь прошел проверку подлинности — скрипт выполняется.
Проверка подлинности осуществляется средствами web-сервера.
Авторизация предполагает проверку прав доступа пользователя к каким-либо ресурсам. Поскольку в данном случае «ресурсы» заключаются в праве выполнить скрипт OneScript — какого-либо отдельного механизма авторизации нет, поскольку мы имеем одно право для назначения.
Или я что-то не так понял?
(5)
Развертывание рабочего сервера OneScript фактически сводится к публикации этого приложения на web-сервере Apache или IIS в операционных системах Linux или Windows.
Т.е. на каждом «рабочем сервере onescript» нужно ОБЯЗАТЕЛЬНО устанавливать веб сервер.
Затем на этот «рабочий сервер onescript» «каркасная конфигурация» скопирует zip архив (из макета) с *.exe файлами движка OS, коннекторами и *.os файлами.
Затем необходимо «вручную» регистрировать веб-приложение из zip архива на веб сервере.
После чего веб сервер начинает ждать GET запросы, которые передаются веб приложению, которое выполняет команды на движке OS и возвращает результат.
Я слабо разбираюсь во всем, что связано с Web технологиями и мне не понятно
— кто и зачем запускает runscript.os и callmethod.os и в какой момент времени. Кто отслеживает состояние работы службы Веб Сервера и процессов, под которыми работают .os скрипты?
— под какими правами запускается веб приложение. На сколько я понимаю, то под правами пользователя службы (демона) веб сервера. Следовательно, например для манипуляции с файлами в корне системного диска этот пользователь должен быть локальным админом.
— как гарантируется что другая «каркасная конфигурация» в этой же локальной сети какого-нить «хакера» не выполнит команду на «рабочий сервер onescript»?
Не до конца понимаю: зачем использовать web-сервер (кроме неоспоримого удобства), если с «рабочим сервером OneScript» можно взаимодействовать «из коробки» по SSH и без Web-сервера. Может я предлагаю пургу, но почему бы по ssh не запустить runscript.os и callmethod.os скрипты через openscript.exe с параметрами, аналогичными запросу Post? А ответ получать из файла-ответа (я точно не знаю что можно получить в коде возврата ssh команд).
Понимаю, что текстовый файл-ответа далек от удобного ответа в формате OData веб-сервера. Но если нужен ответ именно OData, то по мне логично перетянуть файл-ответ на сервер «каркасной конфигурации», на этом же сервере развернуть web-сервер, и через эту-же конфигурацию преобразовывать текст файла в OData веб-сервера.
Мне просто страшно представить себе, как я подхожу к админам и говорю «а давайте для упрощения администрирования серверов (в том числе продакшн 1С) поставим на все по веб-серверу и откроем 80 порт».
Вот теперь я разобрался в общем принципе работы:
— управляющая каркасная конфигурация 1C посылается post запросы с параметрами выполнения команд на Веб-сервис кластера нодов серверов приложений OneScript,
— те в свою очередь локальным фоновым заданием по ssh отправляют команды на обслуживаемые серверы.
— затем ответ веб-сервисом отсылается в каркасную конфигурацию с результатом работы каждого фонового задания.
Но мне все-равно не понятно: чем обусловлена необходимость использования Веб-сервиса на сервере приложений OneScript. Если для прозрачного масштабирования количества серверов приложений OneScript, то почему бы для этого не использовать кластер серверов приложений 1С с назначением функциональности на выполнение фоновых заданий. И функциональность больше, и «порог входа» ниже, хотя и дороже из-за лицензии на серверы приложений 1С.
— те в свою очередь локальным фоновым заданием по ssh отправляют команды на обслуживаемые серверы.
— затем ответ веб-сервисом отсылается в каркасную конфигурацию с результатом работы каждого фонового задания.
Да, все так
В общем случае, Вы не обязаны использовать рабочие серверы OneScript или PowerShell если Ваши задачи могут быть решены средствами платформы 1С:Предприятие.
Использование рабочих серверов может понадобиться в случаях, когда вы не можете решить задачу средствами 1С или ее решение штатными средствами платформы неэффективно, а также в случаях, если вы ограничены в лицензиях или производительности вашей инфраструктуры 1С.
Я плохо сформулировал свой прошлый вопрос, перефразирую максимально развернуто:
Если исключить ограничение лицензий серверов приложений 1С, то в чем преимущество повышения производительность обслуживающих серверов через увеличение количества нодов веб-сервера с сервером приложения OneScript на каждом ноде перед повышением производительности через увеличение количества серверов приложений 1С в кластере (серверов приложений 1С) с сервером приложений OneScript на каждом?
(13)Ну если полностью отбросить лицензирование и предположить использование только стандартных функций платформы в 1С и их аналогов в OneScript то вполне возможно, что особой разницы и каких-либо преимуществ не будет. Возможно где-то OneScript будет в чем-то медленнее, а в чем-то быстрее. Глобальных сравнительных тестов по каждой функции я не проводил ввиду их трудоемкости. Возможно у Андрея Овсянкина есть более детальная информация. Могу лишь сказать, что оценочные тесты вызова http-сервисов OneScript с выполнением функции а-ля hello world показали результаты сравнимые с php, что быстрее, чем использование http-сервисов платформы, однако эти результаты не будут адекватными для больших сложных алгоритмов, написанных на внутреннем языке.
(14)
Вы сравниваете кластер серверов приложений 1С и веб-сервис из кластера нодов-серверов приложений OneScript по производительности и функциональности.
У меня вопрос в другом:
Зачем нужен веб-сервис, если можно использовать кластер серверов приложений 1С (который будет распределять нагрузку и отказоустойчивость также как и веб-сервис с нодам), на каждом сервере приложения которого поставить сервер приложения OneScript (рядом с сервер-приложением 1С). На этот же кластер серверов приложений 1С «прописать» каркасную конфигурацию, которая будет напрямую вызывать OneScript (не используя веб-сервер) на самом не загруженном сервере приложений 1С кластера. Для лучшей и более прогнозируемой масштабируемости системы кластера 1С сделать назначение функциональности = только фоновые задания и сделать все сервера «главными» (для отказоустойчивости).
Предложенный Вами вариант конечно возможен, однако появляется ряд вопросов с технической реализацией:
Как технически реализуется прямое взаимодействие? Мне на ум приходит только внешняя компонента по технологии NativeAPI (для работы в среде Windows и Linux), которая будет мостом, между 1С и библиотеками .NET., коими по факту является OneScript. Думаю, что создание и поддержка такой компоненты — достаточно нетривиальное и ресурсоемкое занятие (на мой взгляд без видимых преимуществ).
Как Вы планируете исключить влияние выполнения Ваших скриптов на продуктивную систему?
Ведь в процессе работы с компонентой, при использовании сторонних библиотек (а иначе зачем это все, если возможна реализация средствами платформы) возможны ситуации с утечками памяти или вообще с остановкой службы. Учитывая, что на Вашем кластере будут размещены и другие информационные базы — это может привести к нестабильной работе не только Ваших сервисов, но и производственных баз. Конечно как вариант, можно создать отдельные службы для технологических баз и соответственно отдельный кластер, однако это усложнит обслуживание и обновление системы и по большому счету не решит проблем стабильности (ну да, Вы сможете безболезненно перезапускать службы 1С без влияния на продуктивные базы, тем самым освобождая память).
(16)
Ранее Вы писали:
(10)
Значит:
Каркасная конфигурация может слать (от лица службы приложения 1С, что для веб-сервиса индифферентно) POST запросы к «рабочему веб-серверу» по http(s), который перенаправляет параметры требуемых к выполнению команд на «библиотеки .NET, коими по факту является OneScript». Сами эти «библиотеки .NET» имеют коннекторы даже к СУБД, но возможности напрямую (без веб-сервиса) получать от расположенный на этом же компьютере службы приложения 1С команды типа: «а ну-ка подключись к такому-то компьютеру по ssh и выполни-ка такие-вот действия» даже НЕ РАССМАТРИВАЛАСЬ разработчиками.
В этом и суть моего вопроса: почему веб-сервис обязателен, зачем этот посредник? Что такого может веб-сервис, чего не может сделать служба приложений 1С?
Зачем нужен Nativ API для передачи команд на локальном компьютере? Если параметры требуемых к исполнению команд укладываются в POST запрос, значит их также можно уложить в параметры вызова OneScript.exe (т.е. *.os файлов-скриптов) без кардинальных преобразований через
На крайний случай для минимальной переделки (в первую очередь из-за проблем с допустимыми символами) записывать весь POST запрос от службы приложения 1С в файл, который передавать параметром на OS скрипт типа runcommandinfile.os.
(17)
unscript.os» /ПараметрыPostЗапроса).
Помимо того, что это как минимум на порядок более медленная реализация (Вы каждый запрос запускаете исполняемый файл, который должен быть считан с диска, каждый запрос вынуждены инициализировать среду выполнения OneScript и необходимые библиотеки) так еще будете вынуждены создавать кучу файлов для транспорта данных (работа с которыми также на порядки более медленная), за которыми надо будет следить: удалять после получения результатов, а также чистить мусор после неудачного выполнения etc. Зачем эта головная боль, когда все можно сделать в памяти быстро и красиво, обратившись к http-сервису?
(18) Почему вообще (я, по крайней мере, не нашел) не рассматривается запуск приложения OneScript в роли службы (демона) для запуска команд OneScript удаленно, прослушивая кастомный порт вместо веб-сервиса, также как служба приложения 1С.
Экземпляр EXE и (используемые ранее) библиотеки будет всегда в памяти, контекст инициализирован.
(19) А собственно для чего делать из него службу aka 1С? Вам надо будет самостоятельно организовывать многопоточность, протокол обмена данными, сетевое взаимодействие, кластер высокой доступности etc. Если Вы все это реализуете — у Вас получится своя клиент-серверная платформа 1С. Зачем тратить кучу ресурсов на его создание (с научно-познавательной точки зрения оно конечно интересно)? Чем это будет лучше?
(20)
Я не предлагаю сделать отказоустойчивый кластер серверов приложений OneScript — это слишком жирно. Я предлагаю обеспечивать горизонтальную масштабируемость и отказоустойчивость не через ноды веб-сервера, а через кластер серверов приложений 1С. А OneScript устанавливать на каждый сервер приложений кластера 1С, желательно (для более легкого отслеживания в zabbix) в виде службы.
Это позволит расширить уже существующую инфраструктуру кластеров серверов приложений 1С для запуска множества фоновых заданий на нативном для 1Сника языке через службу-сервис OneScript без:
— затрат клиентских лицензий 1С,
— выделения отдельных серверов для приложений OneScript,
— установок веб-серверов,
— сборки нодов в веб-сервис,
— открытия 80(443) портов,
— сертификатов,
— веб приложений, их развертывания, регистраций, обновлений,
— обвязки новыми агентами мониторинга состояний,
— админа, разбирающегося в веб-технологиях.
Хочется чтобы все было как «Просто добавь воды»:
— пропиши «каркасную» конфигурацию в уже настроенный кластер 1С,
— запусти службу OneScript на каждом сервере это кластера,
— добавь службу OneScript в мониторинг.
(21) P.S. Если не секрет — какая у вас инфраструктура 1С, что хотели-бы автоматизировать (если хотите — можно в личку)?
(24)
Ну смотрите:
У Вас есть некая конфигурация 1С «Скрипт менеджер» на единственном сервере приложений 1С. В случае использования АИТП + OneScript у вас также будет служебная конфигурация.
Эта конфигурация использует выполнение запросов к СУБД MSSQL через sqlcmd. Из этого можно сделать вывод, что крутится все это на сервере под управлением ОС Windows и вам нужна функциональность выполнения запросов к СУБД mssql.
В этом конкретном случае Вам не надо разворачивать рабочий сервер OneScript т.к. в комплекте с конфигурацией идут библиотеки, оформленные как COM объекты, которые позволяют Вам реализовать выполнение запросов напрямую из 1С без использования рабочих серверов. Вам достаточно выгрузить содержимое общего макета РаботаСУБДCOMОбъект разархивировать его и зарегистрировать через regsvr32. После этого Вы можете выполнять запросы напрямую из 1С.
Это самый простейший вариант.
Чуть погодя расширю на использование рабочего сервера OneScript.
(25)Да, совсем забыл написать. Библиотека реализована на основе штатной .net библиотеки от MS. и соответственно поддерживает все функции, включая шифрование.
(25)Собственно использование COM объекта эквивалентно тому, что sqlcmd находится на сервере приложений 1С и вы при помощи него подключаетесь к sql серверам или как если бы Вы подключались к ним с использованием SQL Server Management Studio.
Если я правильно понял — у вас сейчас так и происходит.
Если данный подход по каким-то причинам считается небезопасным (скажем удаленные соединения с SQL Server могут быть взломаны), то можно организовать IPSec в транспортном режиме между Вашим сервером приложений и SQL-серверами. Конечно это потребует некоторой работы от админов, однако это опять-таки штатные действия по защите сети и собственно это они знают и умеют (по крайней мере должны).
P.S. И все-таки как это реализовано в настоящее время? sqlcmd находится на сервере 1С предприятие и соединяется с SQL серверами по сети или конфигурация каким-то образом подключается к sql-серверам и уже там запускает sqlcmd?
Теперь рассмотрим ситуацию с использованием рабочего сервера OneScript:
В настоящее время вы используете конфигурацию «Скрипт менеджер», вместо нее предполагается использование конфигурации АИТП. В этой части, никакого усложнения инфраструктуры и каких-либо дополнительных требований не возникает.
Для использования рабочего сервера OneScript необходимо наличие web-сервера, который можно развернуть на сервере приложений 1С:Предприятие. Поскольку в вашем случае web-сервер и сервер 1С находятся на одном компьютере, нет необходимости выставлять его (web-сервер) в корпоративную сеть. Для этого вы можете сконфигурировать web-сервер таким образом, чтобы он работал только на внутреннем адресе 127.0.0.1 (loopback interface). В этом случае коммуникации будут происходить внутри вашей виртуальной машины и не попадут в корпоративную сеть. Таким образом у вас отпадает необходимость в использовании https т.к. траффик может быть перехвачен и проанализирован только если злоумышленник завладеет вашим сервером 1С. В настройках подключения к http-серверу также необходимо будет указать адрес 127.0.0.1.
Относительно удаленного подключения к sql серверу действуют принципы изложенные выше. Поскольку на сколько я понимаю ваша инфраструктура построена на базе MS Windows, для подключения к sql серверам имеет смысл использовать интегрированную проверку подлинности windows. Т.е. ваш web-сервер работает из под доменного аккаунта и вы должны назначить ему соответствующие права на sql серверах. В этом случае отпадает необходимость в хранении пароля, а также в его передаче по сети. Этот пункт также относится и к варианту использования COM компонентов напрямую. Только в этом случае служба 1С должна работать из под доменной учетной записи.
Таким образом, за исключением установки роли web-сервера в варианте, когда вы используете рабочий сервер, никакого дополнительного усложнения вроде как и нет.
(27) Да, sqlcmd установлен на сервере приложений 1С. Конфигурация 1С посылает команды к инстансам SQL через запуск локального sqlcmd.exe под правами служебного [СВЕРХСЕКРЕТНОГО] пользователя (который является админом всех SQL серверов) службы приложения 1С сервера, и в параметрах подставляет наименование инстанса и текст запроса-инструкции на T-SQL.
Не интересовался тонкостями взаимодействия серверов приложений 1С с SQL-серверами. Могу сказать, что у СБ нет вопросов по безопасности, т.к. всюду используется только доменная авторизация, а пароль к пользователю службы приложения 1С знают только БИГ-боссы.
(29) Ну тогда Ваш вариант — установка и регистрация COM компоненты для работы с СУБД. Похоже, что больше ничего не потребуется.
Не знаю, какие скрипты вы выполняете, м.б. такие права и требуются, однако если Вы работаете с определенными базами — лучше ограничить доступ только к ним.
Логин и пароль секретного пользователя передается в sqlcmd? или используется проверка подлинности Windows (логин и пароль не передаются)?
Возможно имеет смысл наделить этот аккаунт, если он доменный правами на sql-серверах.
(28) Согласен, в такой реализации проблем с безопасностью действительно нет, если post запросы разрешить только с localhost. Но будет ворчание админов о совмещении ролей сервера IIS и сервера приложения 1С на одной машине, что как-бы немного противоречит общей концепции построения инфраструктуры.
И соглашусь, что работа с SQL через COM намного привычнее, чем работа через вызов EXE с параметрами.
В ближайшее время плотнее разберу функционал АИТП.
Но мне [, упёртому барану,] по прежнему не понятно, почему нельзя реализовать запуск OneScript.exe (для удобства добавив его в переменную среды Path) по тому же протоколу SSH с параметрами запуска, содержащего прямой текст кода 1С, как это сделано для sqlcmd (куда передаются прямые инструкции T-SQL). Да, понимаю, каждый раз происходит инициализация вместе с библиотеками в отдельных запущенных экземплярах EXE файла вместо одной службы IIS. И ответ будет не такой «красивый и удобный», как тот же OData.
(30) Так и сделано: Секретный пользователю службы приложения 1С кластера управления является админом SQL серверов, поэтому при вызове sqlcmd используется windows авторизация и логин-пароль не передается.
Права именно админа инстансов требуется службе приложения 1С для быстрого разворачивания средствами только «Скрипт менеджера» копий рабочих баз для отладки на отличных (как правило) от продашн SQL-серверах, что средствами MS SQL SMS можно делать только зная либо «секретного» пользователя, либо быть админом SQL и обладать правами RW на копирование FULL.bak файла между локальными дисками SQL серверов.
(31)
Да можно же и так 🙂 Я Вам не говорил, что нельзя. Зачем мучать себя?