0. blackhole321 1040 22.05.19 00:10 Сейчас в теме

АИТП. Подсистема взаимодействия с рабочими серверами OneScript

В статье описан механизм взаимодействия конфигурации АИТП с рабочими серверами OneScript.

Перейти к публикации

Лучшие комментарии
10. blackhole321 1040 12.09.19 18:07 Сейчас в теме
Мне просто страшно представить себе, как я подхожу к админам и говорю "а давайте для упрощения администрирования серверов (в том числе продакшн 1С) поставим на все по веб-серверу и откроем 80 порт".


Ах вот оно что :)
У Вас сложилось неправильное представление о предполагаемом механизме использования и по всей видимости - это моя вина. Конечно не нужно устанавливать web-сервер и OneScript и это вот все на каждый управляемый сервер/устройство.
Собственно рабочие сервера - это не устройства, которыми Вы хотите управлять, а некий аналог сервера приложений 1С. Фактически Вы обращаетесь к "рабочему серверу" по http(s) и "говорите": а ну-ка подключись к такому-то компьютеру по ssh и выполни-ка такие-вот действия. Вы можете запустить выполнение нескольких параллельных скриптов для выполнения различных действий с различными серверами на одном рабочем сервере, поскольку он многопоточный. Причем в минимальном случае - достаточно одного "рабочего сервера". Количество рабочих серверов определяется требованиями по обеспечению высокой доступности и необходимой производительностью.
То есть, Вы можете использовать ОДИН рабочий сервер для управления скажем 100 серверами.
Поскольку фактически "рабочие серверы" являются web-серверами Вы можете кластеризовать их. Для Windows - это технология NLB, пример для Linux описан в статье: https://infostart.ru/public/1057169/
Таким образом Вы распределяете нагрузку между ними, а также обеспечиваете высокую доступность, поскольку при выходе из строя одного/нескольких сервера(ов) Ваши скрипты будут выполняться на оставшихся серверах (нодах).

Не до конца понимаю: зачем использовать web-сервер (кроме неоспоримого удобства), если с "рабочим сервером OneScript" можно взаимодействовать "из коробки" по SSH и без Web-сервера.
Может я предлагаю пургу, но почему бы по ssh не запустить runscript.os и callmethod.os скрипты через openscript.exe с параметрами, аналогичными запросу Post? А ответ получать из файла-ответа (я точно не знаю что можно получить в коде возврата ssh команд).

Такой вариант в принципе возможен, если Вы будете использовать внешнюю компоненту, написанную по технологии NativeAPI для работы с ssh, которая должна работать и в Linux и в Windows. В этом случае Вы можете не использовать OneScript, а управлять серверами напрямую из 1С. Но тут могут всплыть ньюансы с утечками памяти и многопоточностью, а также с нагрузкой на сам сервер приложений 1С, масштабирование которого стоит денег.
Остальные комментарии
Избранное Подписка Сортировка: Древо
1. YPermitin 5017 22.05.19 09:14 Сейчас в теме
(0) OneScript набирает популярность. До сих пор удивляюсь, но раз сообщество использует, значит все не зря!

+
2. Steelvan 22.05.19 10:26 Сейчас в теме
Примеры сугубо профессиональные с очень узкой нишей. Надо более массовое.
3. blackhole321 1040 23.05.19 08:33 Сейчас в теме
(2)Это пока что-то типа документации по развертыванию и краткое описание, чтоб можно было установить и попробовать.
Относительно примеров - я Вас услышал, попробую что-нибудь придумать
4. Glebis 11 12.09.19 12:02 Сейчас в теме
Правильно ли я понял: для создания "рабочего сервера onescript" нужно установить onescript, запустить 2 *.os скрипта http сервиса (которые будут обрабатывать запросы по shh или запросы к СУБД).
Самое непонятное для меня после первого прочтения: откуда http сервис берёт последовательно выполнения команд и шаблон результата: из os скриптов, подключается к каркасной конфигурации, мега составной http запрос, каркасная конфигурация должна ныть на каждом рабочем сервере?
Только после 3го прочтения статьи и других указанных материалов у меня появилось предположение, что схема последовательности действия (Рисунок 9) хранится ТОЛЬКО в каркасной конфигурации, которая и посылает следующую команду из последовательности на http сервисы "рабочих серверов onescript" сразу после получения результата выполнения предыдущей команды.
Рекомендую автору более подробно разложить процесс выполнения последовательности команд указанных в схеме процесса.
Еще мне не понятно:
- как запускать os скрипты http сервисов? Как их перезапускать при аварийной остановке процессов?
- как производится проверка легитимности вызова исполняемого кода при вызове через http сервис? Есть ли авторизация на http сервисе?
6. blackhole321 1040 12.09.19 12:45 Сейчас в теме
(4)
Рекомендую автору более подробно разложить процесс выполнения последовательности команд указанных в схеме процесса.


Если Вы подскажете как это получше объяснить и что изменить - я буду Вам безмерно благодарен.

- как запускать os скрипты http сервисов?


Вызовом библиотечной функции OneScriptАИТП.ВыполнитьСкрипт

Как их перезапускать при аварийной остановке процессов?


Пожалуйста, поясните подробнее, о каких процессах идет речь

- как производится проверка легитимности вызова исполняемого кода при вызове через http сервис?


Если не сложно - опишите поподробнее, что Вы имеете ввиду. В настоящее время работа с http-сервисами OneScript происходит также, как если-бы вы работали с web-сервером. Т.е. если обращающийся пользователь прошел проверку подлинности - скрипт выполняется.
Проверка подлинности осуществляется средствами web-сервера.

Есть ли авторизация на http сервисе?


Авторизация предполагает проверку прав доступа пользователя к каким-либо ресурсам. Поскольку в данном случае "ресурсы" заключаются в праве выполнить скрипт OneScript - какого-либо отдельного механизма авторизации нет, поскольку мы имеем одно право для назначения.
Или я что-то не так понял?
5. blackhole321 1040 12.09.19 12:30 Сейчас в теме
Правильно ли я понял: для создания "рабочего сервера onescript" нужно установить onescript, запустить 2 *.os скрипта http сервиса (которые будут обрабатывать запросы по shh или запросы к СУБД).


Не совсем так.
Конфигурация содержит общий макет РабочийСерверOneScriptWebПриложениеАИТП, который представляет собой zip-архив и содержит преднастроенное web-приложение OneScript (включая файлы платформы OneScript и библиотеки) на базе http-сервисов.
Развертывание рабочего сервера OneScript фактически сводится к публикации этого приложения на web-сервере Apache или IIS в операционных системах Linux или Windows.
Публикация на CentOS.
Публикация на Ubuntu
Публикация на Raspberry PI (не все библиотеки могут работать)
Для публикации в IIS - создаете web-приложение, скажем в консоли IIS и копируете содержимое архива в папку web-приложения.

схема последовательности действия (Рисунок 9) хранится ТОЛЬКО в каркасной конфигурации, которая и посылает следующую команду из последовательности на http сервисы "рабочих серверов onescript" сразу после получения результата выполнения предыдущей команды.


Да, именно так. АИТП - это конфигурация 1С (на сколько я понял - Вы назвали ее каркасной) с необходимыми модулями и библиотеками, где Вы создаете в конфигураторе обычный бизнес-процесс в соответствии с некоторыми соглашениями. В момент выполнения задач БП Вы пишете код, который может вызывать http-сервисы OneScript и получать результаты вызова. Фактически Вы отправляете http-запросы, затем получаете и обрабатываете результаты.
7. Glebis 11 12.09.19 15:49 Сейчас в теме
(5)
Конфигурация содержит общий макет РабочийСерверOneScriptWebПриложениеАИТП, который представляет собой zip-архив и содержит преднастроенное web-приложение OneScript (включая файлы платформы OneScript и библиотеки) на базе http-сервисов.
Развертывание рабочего сервера OneScript фактически сводится к публикации этого приложения на web-сервере Apache или IIS в операционных системах Linux или Windows.

Т.е. на каждом "рабочем сервере onescript" нужно ОБЯЗАТЕЛЬНО устанавливать веб сервер.
Затем на этот "рабочий сервер onescript" "каркасная конфигурация" скопирует zip архив (из макета) с *.exe файлами движка OS, коннекторами и *.os файлами.
Затем необходимо "вручную" регистрировать веб-приложение из zip архива на веб сервере.
После чего веб сервер начинает ждать GET запросы, которые передаются веб приложению, которое выполняет команды на движке OS и возвращает результат.

Я слабо разбираюсь во всем, что связано с Web технологиями и мне не понятно
- кто и зачем запускает runscript.os и callmethod.os и в какой момент времени. Кто отслеживает состояние работы службы Веб Сервера и процессов, под которыми работают .os скрипты?
- под какими правами запускается веб приложение. На сколько я понимаю, то под правами пользователя службы (демона) веб сервера. Следовательно, например для манипуляции с файлами в корне системного диска этот пользователь должен быть локальным админом.
- как гарантируется что другая "каркасная конфигурация" в этой же локальной сети какого-нить "хакера" не выполнит команду на "рабочий сервер onescript"?
8. blackhole321 1040 12.09.19 16:32 Сейчас в теме
(7)
Т.е. на каждом "рабочем сервере onescript" нужно ОБЯЗАТЕЛЬНО устанавливать веб сервер.

Да

Затем на этот "рабочий сервер onescript" "каркасная конфигурация" скопирует zip архив (из макета) с *.exe файлами движка OS, коннекторами и *.os файлами.
Затем необходимо "вручную" регистрировать веб-приложение из zip архива на веб сервере.

Нет. Вы копируете содержимое архива на web-сервер.
После чего веб сервер начинает ждать GET запросы, которые передаются веб приложению, которое выполняет команды на движке OS и возвращает результат

Да, только запросы POST, чтобы можно было передать скрипт и параметры.

Я слабо разбираюсь во всем, что связано с Web технологиями

Ничего страшного :) Вы всегда можете задать вопрос и прояснить неясные моменты.

кто и зачем запускает runscript.os и callmethod.os и в какой момент времени.

Эти скрипты запускаете Вы из 1С при вызове функций OneScriptАИТП.ВыполнитьСкрипт и OneScriptАИТП.ВыполнитьМетод соответственно. Ну а момент времени зависит от Вас - тогда, когда хотите выполнить скрипт или метод.
Эти скрипты - обработчики Ваших http-запросов. Они и запускают на выполнение Ваш код, собирают и возвращают результаты его выполнения.

Кто отслеживает состояние работы службы Веб Сервера и процессов, под которыми работают .os скрипты?

Процессы служб web-сервера никто не отслеживает, это стандартные службы, используемые для отдачи html страниц etc., однако Вы можете периодически проверять работоспособность сервисов посредством периодического выполнения тестовых скриптов и вызова тестовых методов. Этот функционал штатно реализован.
Конечно Вы можете подключиться к web-серверу в т. ч. из OneScript и проверить состояние служб штатными средствами ОС.

- под какими правами запускается веб приложение. На сколько я понимаю, то под правами пользователя службы (демона) веб сервера.

Да, именно так.
Вопрос в том - зачем Вам манипулировать файлами системного диска. По идее - рабочий сервер - это сервер приложений, который выполняет некоторые действия. Аккаунт из под которого производится выполнение должен обладать минимальными правами. Если Вам необходимо изменить произвольные системные файлы и папки
то да, либо административные права аккаунту, что плохо, либо из скрипта подключаетесь к этому хосту по ssh с аккаунтом, обладающим административными правами и производите необходимые действия.

- как гарантируется что другая "каркасная конфигурация" в этой же локальной сети какого-нить "хакера" не выполнит команду на "рабочий сервер onescript"?


Для исключения такой ситуации необходимо использовать службы проверки подлинности Вашего web-сервера (логин/пароль или Windows-проверка), а также ограничение запросов по ip-адресам (чтобы обрабатывались только запросы с Вашего/х серверов). В статье https://infostart.ru/public/1058386/ эти вопросы достаточно подробно рассмотрены (применительно к CentOS) .
9. Glebis 11 12.09.19 17:35 Сейчас в теме
Не до конца понимаю: зачем использовать web-сервер (кроме неоспоримого удобства), если с "рабочим сервером OneScript" можно взаимодействовать "из коробки" по SSH и без Web-сервера. Может я предлагаю пургу, но почему бы по ssh не запустить runscript.os и callmethod.os скрипты через openscript.exe с параметрами, аналогичными запросу Post? А ответ получать из файла-ответа (я точно не знаю что можно получить в коде возврата ssh команд).
Понимаю, что текстовый файл-ответа далек от удобного ответа в формате OData веб-сервера. Но если нужен ответ именно OData, то по мне логично перетянуть файл-ответ на сервер "каркасной конфигурации", на этом же сервере развернуть web-сервер, и через эту-же конфигурацию преобразовывать текст файла в OData веб-сервера.

Мне просто страшно представить себе, как я подхожу к админам и говорю "а давайте для упрощения администрирования серверов (в том числе продакшн 1С) поставим на все по веб-серверу и откроем 80 порт".
10. blackhole321 1040 12.09.19 18:07 Сейчас в теме
Мне просто страшно представить себе, как я подхожу к админам и говорю "а давайте для упрощения администрирования серверов (в том числе продакшн 1С) поставим на все по веб-серверу и откроем 80 порт".


Ах вот оно что :)
У Вас сложилось неправильное представление о предполагаемом механизме использования и по всей видимости - это моя вина. Конечно не нужно устанавливать web-сервер и OneScript и это вот все на каждый управляемый сервер/устройство.
Собственно рабочие сервера - это не устройства, которыми Вы хотите управлять, а некий аналог сервера приложений 1С. Фактически Вы обращаетесь к "рабочему серверу" по http(s) и "говорите": а ну-ка подключись к такому-то компьютеру по ssh и выполни-ка такие-вот действия. Вы можете запустить выполнение нескольких параллельных скриптов для выполнения различных действий с различными серверами на одном рабочем сервере, поскольку он многопоточный. Причем в минимальном случае - достаточно одного "рабочего сервера". Количество рабочих серверов определяется требованиями по обеспечению высокой доступности и необходимой производительностью.
То есть, Вы можете использовать ОДИН рабочий сервер для управления скажем 100 серверами.
Поскольку фактически "рабочие серверы" являются web-серверами Вы можете кластеризовать их. Для Windows - это технология NLB, пример для Linux описан в статье: https://infostart.ru/public/1057169/
Таким образом Вы распределяете нагрузку между ними, а также обеспечиваете высокую доступность, поскольку при выходе из строя одного/нескольких сервера(ов) Ваши скрипты будут выполняться на оставшихся серверах (нодах).

Не до конца понимаю: зачем использовать web-сервер (кроме неоспоримого удобства), если с "рабочим сервером OneScript" можно взаимодействовать "из коробки" по SSH и без Web-сервера.
Может я предлагаю пургу, но почему бы по ssh не запустить runscript.os и callmethod.os скрипты через openscript.exe с параметрами, аналогичными запросу Post? А ответ получать из файла-ответа (я точно не знаю что можно получить в коде возврата ssh команд).

Такой вариант в принципе возможен, если Вы будете использовать внешнюю компоненту, написанную по технологии NativeAPI для работы с ssh, которая должна работать и в Linux и в Windows. В этом случае Вы можете не использовать OneScript, а управлять серверами напрямую из 1С. Но тут могут всплыть ньюансы с утечками памяти и многопоточностью, а также с нагрузкой на сам сервер приложений 1С, масштабирование которого стоит денег.
11. Glebis 11 13.09.19 11:36 Сейчас в теме
Вот теперь я разобрался в общем принципе работы:
- управляющая каркасная конфигурация 1C посылается post запросы с параметрами выполнения команд на Веб-сервис кластера нодов серверов приложений OneScript,
- те в свою очередь локальным фоновым заданием по ssh отправляют команды на обслуживаемые серверы.
- затем ответ веб-сервисом отсылается в каркасную конфигурацию с результатом работы каждого фонового задания.
Но мне все-равно не понятно: чем обусловлена необходимость использования Веб-сервиса на сервере приложений OneScript. Если для прозрачного масштабирования количества серверов приложений OneScript, то почему бы для этого не использовать кластер серверов приложений 1С с назначением функциональности на выполнение фоновых заданий. И функциональность больше, и "порог входа" ниже, хотя и дороже из-за лицензии на серверы приложений 1С.
12. blackhole321 1040 13.09.19 12:34 Сейчас в теме
- управляющая каркасная конфигурация 1C посылается post запросы с параметрами выполнения команд на Веб-сервис кластера нодов серверов приложений OneScript,
- те в свою очередь локальным фоновым заданием по ssh отправляют команды на обслуживаемые серверы.
- затем ответ веб-сервисом отсылается в каркасную конфигурацию с результатом работы каждого фонового задания.


Да, все так

чем обусловлена необходимость использования Веб-сервиса на сервере приложений OneScript.


В общем случае, Вы не обязаны использовать рабочие серверы OneScript или PowerShell если Ваши задачи могут быть решены средствами платформы 1С:Предприятие.
Использование рабочих серверов может понадобиться в случаях, когда вы не можете решить задачу средствами 1С или ее решение штатными средствами платформы неэффективно, а также в случаях, если вы ограничены в лицензиях или производительности вашей инфраструктуры 1С.
13. Glebis 11 13.09.19 16:36 Сейчас в теме
Я плохо сформулировал свой прошлый вопрос, перефразирую максимально развернуто:
Если исключить ограничение лицензий серверов приложений 1С, то в чем преимущество повышения производительность обслуживающих серверов через увеличение количества нодов веб-сервера с сервером приложения OneScript на каждом ноде перед повышением производительности через увеличение количества серверов приложений 1С в кластере (серверов приложений 1С) с сервером приложений OneScript на каждом?
14. blackhole321 1040 13.09.19 19:14 Сейчас в теме
(13)Ну если полностью отбросить лицензирование и предположить использование только стандартных функций платформы в 1С и их аналогов в OneScript то вполне возможно, что особой разницы и каких-либо преимуществ не будет. Возможно где-то OneScript будет в чем-то медленнее, а в чем-то быстрее. Глобальных сравнительных тестов по каждой функции я не проводил ввиду их трудоемкости. Возможно у Андрея Овсянкина есть более детальная информация. Могу лишь сказать, что оценочные тесты вызова http-сервисов OneScript с выполнением функции а-ля hello world показали результаты сравнимые с php, что быстрее, чем использование http-сервисов платформы, однако эти результаты не будут адекватными для больших сложных алгоритмов, написанных на внутреннем языке.
15. Glebis 11 16.09.19 09:20 Сейчас в теме
(14)
Ну если полностью отбросить лицензирование и предположить использование только стандартных функций платформы в 1С и их аналогов в OneScript то вполне возможно, что особой разницы и каких-либо преимуществ не будет

Вы сравниваете кластер серверов приложений 1С и веб-сервис из кластера нодов-серверов приложений OneScript по производительности и функциональности.
У меня вопрос в другом:
Зачем нужен веб-сервис, если можно использовать кластер серверов приложений 1С (который будет распределять нагрузку и отказоустойчивость также как и веб-сервис с нодам), на каждом сервере приложения которого поставить сервер приложения OneScript (рядом с сервер-приложением 1С). На этот же кластер серверов приложений 1С "прописать" каркасную конфигурацию, которая будет напрямую вызывать OneScript (не используя веб-сервер) на самом не загруженном сервере приложений 1С кластера. Для лучшей и более прогнозируемой масштабируемости системы кластера 1С сделать назначение функциональности = только фоновые задания и сделать все сервера "главными" (для отказоустойчивости).
16. blackhole321 1040 16.09.19 11:22 Сейчас в теме
Предложенный Вами вариант конечно возможен, однако появляется ряд вопросов с технической реализацией:
на каждом сервере приложения которого поставить сервер приложения OneScript (рядом с сервер-приложением 1С).

каркасную конфигурацию, которая будет напрямую вызывать OneScript (не используя веб-сервер) на самом не загруженном сервере приложений 1С кластера

Как технически реализуется прямое взаимодействие? Мне на ум приходит только внешняя компонента по технологии NativeAPI (для работы в среде Windows и Linux), которая будет мостом, между 1С и библиотеками .NET., коими по факту является OneScript. Думаю, что создание и поддержка такой компоненты - достаточно нетривиальное и ресурсоемкое занятие (на мой взгляд без видимых преимуществ).

Как Вы планируете исключить влияние выполнения Ваших скриптов на продуктивную систему?
Ведь в процессе работы с компонентой, при использовании сторонних библиотек (а иначе зачем это все, если возможна реализация средствами платформы) возможны ситуации с утечками памяти или вообще с остановкой службы. Учитывая, что на Вашем кластере будут размещены и другие информационные базы - это может привести к нестабильной работе не только Ваших сервисов, но и производственных баз. Конечно как вариант, можно создать отдельные службы для технологических баз и соответственно отдельный кластер, однако это усложнит обслуживание и обновление системы и по большому счету не решит проблем стабильности (ну да, Вы сможете безболезненно перезапускать службы 1С без влияния на продуктивные базы, тем самым освобождая память).
17. Glebis 11 16.09.19 12:22 Сейчас в теме
(16)
Как технически реализуется прямое взаимодействие? Мне на ум приходит только внешняя компонента по технологии NativeAPI (для работы в среде Windows и Linux), которая будет мостом, между 1С и библиотеками .NET., коими по факту является OneScript.

Ранее Вы писали:
(10)
Фактически Вы обращаетесь к "рабочему серверу" по http(s) и "говорите": а ну-ка подключись к такому-то компьютеру по ssh и выполни-ка такие-вот действия.

Значит:
Каркасная конфигурация может слать (от лица службы приложения 1С, что для веб-сервиса индифферентно) POST запросы к "рабочему веб-серверу" по http(s), который перенаправляет параметры требуемых к выполнению команд на "библиотеки .NET, коими по факту является OneScript". Сами эти "библиотеки .NET" имеют коннекторы даже к СУБД, но возможности напрямую (без веб-сервиса) получать от расположенный на этом же компьютере службы приложения 1С команды типа: "а ну-ка подключись к такому-то компьютеру по ssh и выполни-ка такие-вот действия" даже НЕ РАССМАТРИВАЛАСЬ разработчиками.
В этом и суть моего вопроса: почему веб-сервис обязателен, зачем этот посредник? Что такого может веб-сервис, чего не может сделать служба приложений 1С?
Зачем нужен Nativ API для передачи команд на локальном компьютере? Если параметры требуемых к исполнению команд укладываются в POST запрос, значит их также можно уложить в параметры вызова OneScript.exe (т.е. *.os файлов-скриптов) без кардинальных преобразований через
Выполнить("С:\...\OneScript.exe" "C:\...\runscript.os" /ПараметрыPostЗапроса).
На крайний случай для минимальной переделки (в первую очередь из-за проблем с допустимыми символами) записывать весь POST запрос от службы приложения 1С в файл, который передавать параметром на OS скрипт типа runcommandinfile.os.
Выполнить("С:\...\OneScript.exe" "C:\...\runcommandinfile.os" "C:\...\FileWithCommands.txt").
18. blackhole321 1040 16.09.19 12:45 Сейчас в теме
(17)
Выполнить("С:\...\OneScript.exe" "C:\...\runscript.os" /ПараметрыPostЗапроса).

Помимо того, что это как минимум на порядок более медленная реализация (Вы каждый запрос запускаете исполняемый файл, который должен быть считан с диска, каждый запрос вынуждены инициализировать среду выполнения OneScript и необходимые библиотеки) так еще будете вынуждены создавать кучу файлов для транспорта данных (работа с которыми также на порядки более медленная), за которыми надо будет следить: удалять после получения результатов, а также чистить мусор после неудачного выполнения etc. Зачем эта головная боль, когда все можно сделать в памяти быстро и красиво, обратившись к http-сервису?
19. Glebis 11 16.09.19 12:49 Сейчас в теме
(18) Почему вообще (я, по крайней мере, не нашел) не рассматривается запуск приложения OneScript в роли службы (демона) для запуска команд OneScript удаленно, прослушивая кастомный порт вместо веб-сервиса, также как служба приложения 1С.
Экземпляр EXE и (используемые ранее) библиотеки будет всегда в памяти, контекст инициализирован.
20. blackhole321 1040 16.09.19 12:59 Сейчас в теме
(19) А собственно для чего делать из него службу aka 1С? Вам надо будет самостоятельно организовывать многопоточность, протокол обмена данными, сетевое взаимодействие, кластер высокой доступности etc. Если Вы все это реализуете - у Вас получится своя клиент-серверная платформа 1С. Зачем тратить кучу ресурсов на его создание (с научно-познавательной точки зрения оно конечно интересно)? Чем это будет лучше?
21. Glebis 11 16.09.19 14:29 Сейчас в теме
(20)
самостоятельно организовывать многопоточность, протокол обмена данными, сетевое взаимодействие, кластер высокой доступности etc

Я не предлагаю сделать отказоустойчивый кластер серверов приложений OneScript - это слишком жирно. Я предлагаю обеспечивать горизонтальную масштабируемость и отказоустойчивость не через ноды веб-сервера, а через кластер серверов приложений 1С. А OneScript устанавливать на каждый сервер приложений кластера 1С, желательно (для более легкого отслеживания в zabbix) в виде службы.
Это позволит расширить уже существующую инфраструктуру кластеров серверов приложений 1С для запуска множества фоновых заданий на нативном для 1Сника языке через службу-сервис OneScript без:
- затрат клиентских лицензий 1С,
- выделения отдельных серверов для приложений OneScript,
- установок веб-серверов,
- сборки нодов в веб-сервис,
- открытия 80(443) портов,
- сертификатов,
- веб приложений, их развертывания, регистраций, обновлений,
- обвязки новыми агентами мониторинга состояний,
- админа, разбирающегося в веб-технологиях.

Хочется чтобы все было как "Просто добавь воды":
- пропиши "каркасную" конфигурацию в уже настроенный кластер 1С,
- запусти службу OneScript на каждом сервере это кластера,
- добавь службу OneScript в мониторинг.
22. blackhole321 1040 16.09.19 15:45 Сейчас в теме
(21)
А OneScript устанавливать на каждый сервер приложений кластера 1С, желательно (для более легкого отслеживания в zabbix) в виде службы


Да Вы можете установить http-сервисы и на существующие сервера приложений если хотите :). Можете собрать это все в ферму, указав в качестве нод сервера 1С. Можете не собирать ферму и обращаться к этим сервисам локально, используя в качестве адреса 127.0.0.1.

Если Вы будете писать службу, то как я описал выше, Вам прийдется реализовать:
проверку подлинности, протокол обмена, сетевое взаимодействие, многопоточность, контроль и освобождение ресурсов etc. Сейчас все эти функции реализованы в web-сервере. Вы предлагаете фактически написать его аналог. Ради чего?
Пожалуйста, если не сложно, расскажите подробнее, что мешает Вам мониторить то, что Вам надо через zabbix в случае существующей реализации?

для запуска множества фоновых заданий через службу-сервис OneScript без:

- затрат клиентских лицензий 1С,

Почему Вы решили, что в текущей реализации Вы должны использовать клиентские лицензии? Вы не обращаетесь к 1С из OneScript (хотя при желании конечно можете).
- выделения отдельных серверов для приложений OneScript,

Вы можете не выделять отдельных физических или виртуальных серверов и использовать для рабочего сервера пространство ОС серверов приложений 1С. Однако надо понимать, что Вы не изолируете выполнение функций, потенциально влияющих на стабильность системы. Тут выбор за Вами.
- установок веб-серверов,

Тут да, однако по моему установка роли web-сервера не является проблемой. К тому-же вместо установки web-сервера Вам будет необходимо устанавливать службу.
- сборки нодов в веб-сервис,

Опять же не вижу в этом проблемы т.к. это по сути дела штатные операции по настройке серверов. К тому-же Вы можете этого не делать, использовав в качестве адреса 127.0.0.1. Только лишь необходимо гарантировать, что код вызывающий асинхронное выполнение и код получающий результаты будет выполнен на одном и том-же сервере приложений.
- открытия 80(443) портов,

Ну если хотите - можете изменить порты на те, которые Вам необходимы.
- сертификатов,

Вы можете не использовать https и в этом случае сертификаты будут не нужны
- веб приложений,

Не совсем понял, что имеется ввиду. Если Вы про копирование содержимого макета то в любом случае при установке какого-либо софта Вам необходимо как-то скопировать его на целевой компьютер.
- обвязки новыми мониторинг-агентами,

Не совсем понял о чем Вы какие мониторинг агенты новые, а какие старые. Если не сложно - пожалуйста поясните Вашу мысль.
- админа, разбирающегося в веб-технологиях.

Как раз-таки для админа установка web-сервера etc. не вызовет никаких сложностей.

Хотелось чтобы все было просто, как "Просто добавь воды": пропиши каркасную конфигурацию в уже существующем кластере 1С и запусти службу OneScript на каждом сервере это кластера, добавь службу в мониторинг.

По сути - оно так и есть :) Установили службу (web-сервер + web-приложение), стартовали, добавили в мониторинг.
Что Вас смущает то :)? Я предлагаю Вам скачать и попробовать ВМЕСТЕ с админом.
23. blackhole321 1040 16.09.19 15:47 Сейчас в теме
(21) P.S. Если не секрет - какая у вас инфраструктура 1С, что хотели-бы автоматизировать (если хотите - можно в личку)?
24. Glebis 11 17.09.19 10:42 Сейчас в теме
(23) Итак, ситуация: Старая конфигурация 1С "Скрипт менеджер", стоит на единственном сервере приложений 1С кластера (на виртуалке), используется для обслуживание продашн SQL инстансов под 1С базы (через sqlcmd.exe из комплекта MS командной строки SQL) и регламентных заданий 1С баз (COM соединением). Изначально у конфигурации было безвременное платное лицензирование сервера приложения 1С (по генерации ключа на основе "железа" виртуальной машины), затем появилось отдельное приложения (exe программы) с той же функциональностью, но с временной лицензией на каждый инстанс SQL, что экономически не приемлемо для нашей организации. Админы намекают, что "железо" виртуалки "сдувается", лицензированный под конфу сервер 1С будет в лучшем случае перенесен, а лицензия перестанет быть актуальной.
Поэтому появляется задача: найти приложение на замену существующей конфигурации обслуживания 1С и SQL серверов, удовлетворяющие следующим критериям:
1) схожей или большей функциональностью,
2) бесплатное или с разовым оплатой,
3) схожим с существующим опытом эксплуатации и настройки,
4) простотой интеграцией в существующую (без её усложнения) инфраструктуру ,
5) не снижающей уровень сохранности данных и безопасности инфраструктуры организации.

И тут я нахожу ваше решение решение на OneScript, которое удовлетворяет критериям 1), 2), и даже 3). И тут я иду к админам и говорю:
- Нам, 1Сникам, нужен отдельный сервер с ролью ISS (или Апачем), открытым кастомный портом для метода post.
Получаю ответ:
- Усложняешь инфраструктуру (п. 4) - пиши СЗ на руководителя IT с обоснованием. Открываешь порты (п. 5) - пиши СЗ на безопасность с обоснованием и перечнем открываемых портов.
Иду к безопаснику, рассказываю про необходимость создания сервера и установки веб-сервиса, про веб-приложение, про COM "средства для интерактивной работы с СУБД". Разговор доходит до того, что необходимо ограничивать доступ к порту веб-сервера по IP сервера кластера управления 1С.
Выясняется, что логин-пароль dbadmin SQL будет летать в открытом HTTP пакете по подсети, поэтому ставьте сертификат и запускайте https, иначе заснифиф пакет можно будет drop`нуть любую таблицу продакшн SQL. Затем возникают всякие другие "а если" вопросы про http сервер, права служб, авторизацию и прочее, на которые я не могу ответить из-за того что не являюсь специалистом по веб-технологиям, а админы не знаю тонкости реализации OneScript.
В итоге админы говорят (и повторят на планерке, если я предложу решение на OneScript), что вместо "всей вашей желтой х**ни с лицензиями, с веб-серверами и сертификатами, веб приложений, открытыми портами, консультаций безопасников, созданием и мониторингом нового сервера, ограничением по IP, и прочего" лишим 1Сников прав DBAdmina SQL, напишем регламенты в MS SQL SMS, 1Сные регламенты нас не интересуют, а админ. доступ к профайлеру будем выдавать 1Сникам только по служебке.

И мне нечем ответить, кроме как "зато не тратятся 2-3 пользовательские лицензии" и "немного расширится функционал".
Я могу предложить развернуть веб-сервис на сервере приложений 1С кластера управления, против чего опять же выступят админы из-за смешивания функциональности серверов.

В общем, к сожалению, я делаю вывод, что интеграция Вашего прикладного решения в текущем варианте предложенной Вами реализации в инфраструктуру нашего предприятия не удовлетворяют критериям 4) и 5). В варианте без использования веб-сервиса, а, например, простой установкой службы OneScript на сервере приложений 1С, мы (1Сники) "проскочили" бы 4) и 5) без вопросов с чье-либо стороны, "внешне" поменяв одну "желтую программу" на другую.
25. blackhole321 1040 17.09.19 11:14 Сейчас в теме
(24)
Ну смотрите:
У Вас есть некая конфигурация 1С "Скрипт менеджер" на единственном сервере приложений 1С. В случае использования АИТП + OneScript у вас также будет служебная конфигурация.
Эта конфигурация использует выполнение запросов к СУБД MSSQL через sqlcmd. Из этого можно сделать вывод, что крутится все это на сервере под управлением ОС Windows и вам нужна функциональность выполнения запросов к СУБД mssql.
В этом конкретном случае Вам не надо разворачивать рабочий сервер OneScript т.к. в комплекте с конфигурацией идут библиотеки, оформленные как COM объекты, которые позволяют Вам реализовать выполнение запросов напрямую из 1С без использования рабочих серверов. Вам достаточно выгрузить содержимое общего макета РаботаСУБДCOMОбъект разархивировать его и зарегистрировать через regsvr32. После этого Вы можете выполнять запросы напрямую из 1С.
Это самый простейший вариант.
Чуть погодя расширю на использование рабочего сервера OneScript.
26. blackhole321 1040 17.09.19 11:23 Сейчас в теме
(25)Да, совсем забыл написать. Библиотека реализована на основе штатной .net библиотеки от MS. и соответственно поддерживает все функции, включая шифрование.
27. blackhole321 1040 17.09.19 12:00 Сейчас в теме
(25)Собственно использование COM объекта эквивалентно тому, что sqlcmd находится на сервере приложений 1С и вы при помощи него подключаетесь к sql серверам или как если бы Вы подключались к ним с использованием SQL Server Management Studio.
Если я правильно понял - у вас сейчас так и происходит.
Если данный подход по каким-то причинам считается небезопасным (скажем удаленные соединения с SQL Server могут быть взломаны), то можно организовать IPSec в транспортном режиме между Вашим сервером приложений и SQL-серверами. Конечно это потребует некоторой работы от админов, однако это опять-таки штатные действия по защите сети и собственно это они знают и умеют (по крайней мере должны).

P.S. И все-таки как это реализовано в настоящее время? sqlcmd находится на сервере 1С предприятие и соединяется с SQL серверами по сети или конфигурация каким-то образом подключается к sql-серверам и уже там запускает sqlcmd?
29. Glebis 11 17.09.19 14:05 Сейчас в теме
(27) Да, sqlcmd установлен на сервере приложений 1С. Конфигурация 1С посылает команды к инстансам SQL через запуск локального sqlcmd.exe под правами служебного [СВЕРХСЕКРЕТНОГО] пользователя (который является админом всех SQL серверов) службы приложения 1С сервера, и в параметрах подставляет наименование инстанса и текст запроса-инструкции на T-SQL.
Не интересовался тонкостями взаимодействия серверов приложений 1С с SQL-серверами. Могу сказать, что у СБ нет вопросов по безопасности, т.к. всюду используется только доменная авторизация, а пароль к пользователю службы приложения 1С знают только БИГ-боссы.
30. blackhole321 1040 17.09.19 14:26 Сейчас в теме
(29) Ну тогда Ваш вариант - установка и регистрация COM компоненты для работы с СУБД. Похоже, что больше ничего не потребуется.

который является админом всех SQL серверов

Не знаю, какие скрипты вы выполняете, м.б. такие права и требуются, однако если Вы работаете с определенными базами - лучше ограничить доступ только к ним.
Логин и пароль секретного пользователя передается в sqlcmd? или используется проверка подлинности Windows (логин и пароль не передаются)?
а пароль к пользователю службы приложения 1С знают только БИГ-боссы

Возможно имеет смысл наделить этот аккаунт, если он доменный правами на sql-серверах.
32. Glebis 11 17.09.19 14:41 Сейчас в теме
(30) Так и сделано: Секретный пользователю службы приложения 1С кластера управления является админом SQL серверов, поэтому при вызове sqlcmd используется windows авторизация и логин-пароль не передается.
Права именно админа инстансов требуется службе приложения 1С для быстрого разворачивания средствами только "Скрипт менеджера" копий рабочих баз для отладки на отличных (как правило) от продашн SQL-серверах, что средствами MS SQL SMS можно делать только зная либо "секретного" пользователя, либо быть админом SQL и обладать правами RW на копирование FULL.bak файла между локальными дисками SQL серверов.
28. blackhole321 1040 17.09.19 12:38 Сейчас в теме
Теперь рассмотрим ситуацию с использованием рабочего сервера 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-сервера в варианте, когда вы используете рабочий сервер, никакого дополнительного усложнения вроде как и нет.
31. Glebis 11 17.09.19 14:28 Сейчас в теме
(28) Согласен, в такой реализации проблем с безопасностью действительно нет, если post запросы разрешить только с localhost. Но будет ворчание админов о совмещении ролей сервера IIS и сервера приложения 1С на одной машине, что как-бы немного противоречит общей концепции построения инфраструктуры.
И соглашусь, что работа с SQL через COM намного привычнее, чем работа через вызов EXE с параметрами.
В ближайшее время плотнее разберу функционал АИТП.

Но мне [, упёртому барану,] по прежнему не понятно, почему нельзя реализовать запуск OneScript.exe (для удобства добавив его в переменную среды Path) по тому же протоколу SSH с параметрами запуска, содержащего прямой текст кода 1С, как это сделано для sqlcmd (куда передаются прямые инструкции T-SQL). Да, понимаю, каждый раз происходит инициализация вместе с библиотеками в отдельных запущенных экземплярах EXE файла вместо одной службы IIS. И ответ будет не такой "красивый и удобный", как тот же OData.
33. blackhole321 1040 17.09.19 15:30 Сейчас в теме
(31)
почему нельзя реализовать запуск OneScript.exe (для удобства добавив его в переменную среды Path) по тому же протоколу SSH с параметрами запуска, содержащего прямой текст кода 1С, как это сделано для sqlcmd (куда передаются прямые инструкции T-SQL).


Да можно же и так :) Я Вам не говорил, что нельзя. Зачем мучать себя?
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Москва
зарплата от 150 000 руб. до 180 000 руб.
Полный день

Программист 1С
Москва
зарплата до 160 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Ведущий программист 1С
Санкт-Петербург
зарплата от 130 000 руб.
Полный день

Программист 1С
Москва
зарплата от 130 000 руб. до 200 000 руб.
Полный день