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

21.07.19

Разработка - OneScript

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

Введение

Ввиду ограниченных штатных возможностей взаимодействия платформы 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. Схема процесса обработки ошибки удаления результатов заданий.

 

Для оперативного контроля, необходимо настроить адресацию задач и оповещения, по методике, описанной в этой статье.

Заключение

Надеюсь, что данная статья поможет Вам в использовании конфигурации АИТП, для автоматизации Ваших процессов.

См. также

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2639    kamisov    17    

56

Что такое ОСень? Или как лучшие практики из мира Java прижились в экосистеме OneScript

OneScript Бесплатно (free)

Думаете, на OneScript неудобно создавать сложные инфраструктурные приложения? Ошибаетесь. Благодаря фреймворку ОСень за последний год экосистема библиотек, упрощающих написание собственных приложений, существенно выросла. Расскажем о самых передовых технологиях OneScript. Спойлер: будет много рефлексии, мета-аннотаций, желудей, напильников и дубов с завязями.

21.11.2023    3016    NikitaIvanchenko    16    

46

Библиотека создания клиент-серверных приложений для сценарного языка OneScript

Инструментарий разработчика Работа с интерфейсом OneScript Россия Бесплатно (free)

Представленная библиотека позволяет создать многопоточный TCP сервер, к которому может одновременно подключиться множество TCP клиентов с удаленных компьютеров. Эти клиенты могут вызывать методы скриптов как на сервере, так и на других клиентах. Методы будут выполнены в контексте скрипта на удаленной машине. Возможна передача параметров в метод и получение результата. Для TCP клиента можно создать графический интерфейс с большим набором элементов управления, модальными диалоговыми окнами и с обработкой событий.

31.07.2023    1976    ahyahy    8    

32

Получаем статистику по git-репозиторию в разрезе разработчиков

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Бесплатно (free)

Итак! Представим, что наступил момент, когда разработка через исходный код реализована на предприятии в полном объеме. Мы разрабатываем в EDT или конфигураторе (но выгружаем конфигурацию в исходный код), версионируем внешние отчеты и обработки и расширения, собираем релизы, проверяем код статическим анализом, в разработке царит гармония и мир. Красота! Но менеджерам этого мало, всегда хочется чего-то еще, и вот мне прилетает задача - дай статистику по вкладу в код каждого разработчика.

13.03.2023    3553    ardn    3    

27

Прокси хранилища 1С (IIS, OneScript)

Групповая разработка (Git, хранилище) OneScript DevOps и автоматизация разработки Платформа 1С v8.3 Россия Бесплатно (free)

Избавляемся от версионной зависимости, проверяем комментарии, вызываем веб-хуки, делаем красивые пути. И все это на привычном IIS и понятном OneScript.

08.12.2022    7991    kamisov    57    

95

OneScript на страже порядка на сервере тестовых баз данных

Администрирование СУБД OneScript Бесплатно (free)

Наводим порядок на сервере тестовых баз с помощью любимого инструмента - OneScript. Находим заброшенные базы на сервере MS SQL, определяем кандидатов на удаление.

14.06.2022    4201    ardn    23    

37

Идем в Serverless с кодом 1С

Облачные сервисы, хостинг OneScript Россия Абонемент ($m)

Запускаем код OneScript в Serverless Container Яндекса.

1 стартмани

29.04.2022    3677    1    papami    2    

9
Отзывы
10. blackhole321 1303 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. пользователь 22.05.19 09:14
(0) OneScript набирает популярность. До сих пор удивляюсь, но раз сообщество использует, значит все не зря!

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


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

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


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

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


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

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


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

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


Авторизация предполагает проверку прав доступа пользователя к каким-либо ресурсам. Поскольку в данном случае "ресурсы" заключаются в праве выполнить скрипт OneScript - какого-либо отдельного механизма авторизации нет, поскольку мы имеем одно право для назначения.
Или я что-то не так понял?
5. blackhole321 1303 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 13 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 1303 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 13 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 1303 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 13 13.09.19 11:36 Сейчас в теме
Вот теперь я разобрался в общем принципе работы:
- управляющая каркасная конфигурация 1C посылается post запросы с параметрами выполнения команд на Веб-сервис кластера нодов серверов приложений OneScript,
- те в свою очередь локальным фоновым заданием по ssh отправляют команды на обслуживаемые серверы.
- затем ответ веб-сервисом отсылается в каркасную конфигурацию с результатом работы каждого фонового задания.
Но мне все-равно не понятно: чем обусловлена необходимость использования Веб-сервиса на сервере приложений OneScript. Если для прозрачного масштабирования количества серверов приложений OneScript, то почему бы для этого не использовать кластер серверов приложений 1С с назначением функциональности на выполнение фоновых заданий. И функциональность больше, и "порог входа" ниже, хотя и дороже из-за лицензии на серверы приложений 1С.
12. blackhole321 1303 13.09.19 12:34 Сейчас в теме
- управляющая каркасная конфигурация 1C посылается post запросы с параметрами выполнения команд на Веб-сервис кластера нодов серверов приложений OneScript,
- те в свою очередь локальным фоновым заданием по ssh отправляют команды на обслуживаемые серверы.
- затем ответ веб-сервисом отсылается в каркасную конфигурацию с результатом работы каждого фонового задания.


Да, все так

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


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

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

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

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

Как Вы планируете исключить влияние выполнения Ваших скриптов на продуктивную систему?
Ведь в процессе работы с компонентой, при использовании сторонних библиотек (а иначе зачем это все, если возможна реализация средствами платформы) возможны ситуации с утечками памяти или вообще с остановкой службы. Учитывая, что на Вашем кластере будут размещены и другие информационные базы - это может привести к нестабильной работе не только Ваших сервисов, но и производственных баз. Конечно как вариант, можно создать отдельные службы для технологических баз и соответственно отдельный кластер, однако это усложнит обслуживание и обновление системы и по большому счету не решит проблем стабильности (ну да, Вы сможете безболезненно перезапускать службы 1С без влияния на продуктивные базы, тем самым освобождая память).
17. Glebis 13 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 1303 16.09.19 12:45 Сейчас в теме
(17)
Выполнить("С:\...\OneScript.exe" "C:\...\runscript.os" /ПараметрыPostЗапроса).

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

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

Хочется чтобы все было как "Просто добавь воды":
- пропиши "каркасную" конфигурацию в уже настроенный кластер 1С,
- запусти службу OneScript на каждом сервере это кластера,
- добавь службу OneScript в мониторинг.
22. blackhole321 1303 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 1303 16.09.19 15:47 Сейчас в теме
(21) P.S. Если не секрет - какая у вас инфраструктура 1С, что хотели-бы автоматизировать (если хотите - можно в личку)?
24. Glebis 13 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 1303 17.09.19 11:14 Сейчас в теме
(24)
Ну смотрите:
У Вас есть некая конфигурация 1С "Скрипт менеджер" на единственном сервере приложений 1С. В случае использования АИТП + OneScript у вас также будет служебная конфигурация.
Эта конфигурация использует выполнение запросов к СУБД MSSQL через sqlcmd. Из этого можно сделать вывод, что крутится все это на сервере под управлением ОС Windows и вам нужна функциональность выполнения запросов к СУБД mssql.
В этом конкретном случае Вам не надо разворачивать рабочий сервер OneScript т.к. в комплекте с конфигурацией идут библиотеки, оформленные как COM объекты, которые позволяют Вам реализовать выполнение запросов напрямую из 1С без использования рабочих серверов. Вам достаточно выгрузить содержимое общего макета РаботаСУБДCOMОбъект разархивировать его и зарегистрировать через regsvr32. После этого Вы можете выполнять запросы напрямую из 1С.
Это самый простейший вариант.
Чуть погодя расширю на использование рабочего сервера OneScript.
26. blackhole321 1303 17.09.19 11:23 Сейчас в теме
(25)Да, совсем забыл написать. Библиотека реализована на основе штатной .net библиотеки от MS. и соответственно поддерживает все функции, включая шифрование.
27. blackhole321 1303 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 13 17.09.19 14:05 Сейчас в теме
(27) Да, sqlcmd установлен на сервере приложений 1С. Конфигурация 1С посылает команды к инстансам SQL через запуск локального sqlcmd.exe под правами служебного [СВЕРХСЕКРЕТНОГО] пользователя (который является админом всех SQL серверов) службы приложения 1С сервера, и в параметрах подставляет наименование инстанса и текст запроса-инструкции на T-SQL.
Не интересовался тонкостями взаимодействия серверов приложений 1С с SQL-серверами. Могу сказать, что у СБ нет вопросов по безопасности, т.к. всюду используется только доменная авторизация, а пароль к пользователю службы приложения 1С знают только БИГ-боссы.
30. blackhole321 1303 17.09.19 14:26 Сейчас в теме
(29) Ну тогда Ваш вариант - установка и регистрация COM компоненты для работы с СУБД. Похоже, что больше ничего не потребуется.

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

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

Возможно имеет смысл наделить этот аккаунт, если он доменный правами на sql-серверах.
32. Glebis 13 17.09.19 14:41 Сейчас в теме
(30) Так и сделано: Секретный пользователю службы приложения 1С кластера управления является админом SQL серверов, поэтому при вызове sqlcmd используется windows авторизация и логин-пароль не передается.
Права именно админа инстансов требуется службе приложения 1С для быстрого разворачивания средствами только "Скрипт менеджера" копий рабочих баз для отладки на отличных (как правило) от продашн SQL-серверах, что средствами MS SQL SMS можно делать только зная либо "секретного" пользователя, либо быть админом SQL и обладать правами RW на копирование FULL.bak файла между локальными дисками SQL серверов.
28. blackhole321 1303 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 13 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 1303 17.09.19 15:30 Сейчас в теме
(31)
почему нельзя реализовать запуск OneScript.exe (для удобства добавив его в переменную среды Path) по тому же протоколу SSH с параметрами запуска, содержащего прямой текст кода 1С, как это сделано для sqlcmd (куда передаются прямые инструкции T-SQL).


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