Как подготовить конфигурацию 1С к миграции сервера приложений на Linux: PostgreSQL, COM, внешние компоненты и пути

Миграция на Linux для конфигурации 1С начинается не с установки ragent, а с аудита серверного кода. Пока база на Microsoft SQL Server, а в общих модулях с флагом «Вызов сервера» остаются СОМ-объекты и внешние компоненты без сборки под Linux, перенос сервера приложений оборвётся на первом фоновом задании. Ниже - подготовка серверной части при клиенте на Windows и обязательной СУБД PostgreSQL: что искать в конфигурации, как читать manifest.xml, куда уводить COM и как согласовать пути обмена со смежными базами на Windows.

Зачем переносить сервер приложений на Linux и что уже проверено

Выгрузка конфигурации: макеты внешних компонент и manifest.xml

Linux для сервера приложений оправдан, когда вы уже живёте на PostgreSQL и хотите снизить стоимость лицензий и зависимость от одного вендора СУБД и ОС. Параллельно проще собрать повторяемый деплой через Ansible или Terraform: роли для платформы 1С, PostgreSQL и мониторинга на Linux складываются в один контур вместо ручных чек-листов на каждом хосте.

В Magnit Tech к миграции серверной части готовили порядка двадцати информационных систем, на Linux перевели семь; остальные проходят тот же цикл аудита конфигурации и нагрузочных прогонов. Узкое место оказалось не в платформе, а в инструментах: мониторинг, обслуживание и домашние скрипты на Linux приходилось донастраивать самим, экспертизу команды подтягивали заранее.

Нагрузочные проверки, в том числе тест Гилева и сценарии с длинными цепочками проводок в ERP, показали: при корректной подготовке конфигурации сервер 1С на Linux по отклику сопоставим с Windows. Эту сопоставимость всё равно нужно подтвердить на вашем стенде с тем же числом сеансов и теми же регламентными заданиями.

Я смотрю на перенос через модель угроз. Каждый вызов New COMObject на сервере после миграции бьёт по доступности всех пользователей, а не даёт локальную ошибку одному клиенту. Мотивация «дешевле Linux» без рефакторинга COM и путей к файлам лишь переносит точку отказа на продуктив.

Контейнеризация ragent не отменяет проверку manifest.xml и не возвращает COM. IaC доставляет одинаковый хост, но не чинит общий модуль с Excel.Application на сервере.

Предусловия: PostgreSQL и пауза стабилизации

Сквозной порядок: Postgres, пауза, аудит, Linux ragent

Главный блокер: сервер приложений 1С на Linux не работает с Microsoft SQL Server. Порядок жёсткий - сначала перевод информационной базы на PostgreSQL, затем, после стабилизации, перенос ragent и кластера на Linux.

После смены СУБД я не трогаю сервер приложений минимум месяц. За этот срок всплывают отличия функций в запросах, collation, неявные приведения типов и регрессы производительности, которых на MSSQL не было.

Запрос с ПОДОБНО, предсказуемый на T-SQL, на PostgreSQL иногда меняет план изR09;за других правил сравнения строк. Это аргумент в пользу паузы, а не повод разворачивать здесь полный гайд по СУБД.

Толстый клиент остаётся на Windows. В зоне риска - серверные процедуры, регламентные задания, НТТР-сервисы и фоновые вызовы. Клиентский COM для Word, не уходящий на сервер, в этой фазе можно не трогать.

Аудит внешних компонент на Linux

Внешние компоненты я собираю по всем точкам: «ПодключитьВнешнююКомпоненту», AttachAddIn, макеты, обёртки в общих модулях. Пропущенная Линух-сборка падает на первом серверном сценарии без UI.

Выгрузите макет в каталог и откройте manifest.xml. Нужны OS Linux x86-64 и type="native" (Native API). Только Windows в манифесте значит, что ragent на Linux компоненту не загрузит.

Если Linux в архиве нет - обновление от поставщика, замена на Native API, перенос на клиент при допустимых правах или временный отказ от функции. Wine на сервере приложений как штатный обход я не рассматриваю.

Инвентаризацию веду через выгрузку в Git или EDT: макеты.zip/.dll и строки «ПодключитьВнешнююКомпоненту» в файлах.bsl. В конфигураторе помогает глобальный поиск по конфигурации.

AttachAddIn на формах с серверной записью проверяю отдельно: сервер не должен инициировать компоненту там, где после переноса останется только Linux ragent.

После правок прогоните сценарий на стенде под srv1cv8 без админских прав ОС. Иначе на продуктиве всплывут отказы записи в каталог компоненты.

Если поставщик прислал несколько архитектур в одном zip, не путайте x86-32 и x86-64. Ragent на современном дистрибутиве обычно x86-64, а старый манифест с одной 32-битной строкой создаёт ложное ощущение совместимости.

Компоненты из макетов «на время сеанса» тоже попадают в аудит, если их инициирует серверная процедура записи документа. Такие места я отдельно помечаю в списке блокеров, чтобы при cutover не спорить, кто первый вызвал AddIn.

СОМ-объекты: сервер Linux и ловушки внешних баз

НТТР-сервис на Linux ragent вместо COMConnector

На сервере приложений Linux COM для кода 1С не исполняется. New COMObject, CreateObject, WScript.Shell, Excel.Application, Word.Application, COMConnector в «Вызов сервера», регламенте или НТТР-сервисе после миграции дадут ошибку или подвисание очереди фоновых заданий.

На сервере после cutover остаются НТТР-сервисы, веб-сервисы платформы, файлы в mountpoint и PostgreSQL. Word и Excel допустимы на Wиндоwс-клиенте, если бизнес принимает клиентскую зависимость и вызов не утекает на сервер.

Обмен между базами вместо COM я закладываю через НТТРСервис: URLTemplate, методы модуля НТТР-сервиса, аутентификация на публикации, контракт JSON. Публикацию поднимаю на Линух-стенде заранее, чтобы версия платформы совпала с будущим ragent.

База на Windows через COMConnector может дернуть вашу базу на Linux, а внутри сеанса выполнится серверный модуль с COM. Технологический журнал с CALL, EXCP и порогом длительности показывает такие цепочки; дальше правлю параметры узла или переношу контракт на HTTP на стороне источника.

Типичный сбой: внешняя база передавала UNC \\fileserver\exchange\in, Linux ждал /mnt/exchange/in. Пока константу узла не поправили в Wиндоwс-базе, регламент падал на записи файла.

Новый COM в конфигурации у нас под запретом регламентом. SonarQube и языковой сервер для кода 1С ловят регресс в merge; расширения и внешние EPF всё равно прохожу вручную.

Шаблоны поиска: «СОМОбъект», «CreateObject», «New COMObject», «WScript», «Excel.Application», «COMConnector».

Контексты в коде 1С развожу буквально. Процедуры с COM получают &НаКлиенте или уходят в клиентский общий модуль без «Вызов сервера»; сервер принимает уже готовый двоичный файл или JSON. Вариант «сервер создаёт COM, клиент только жмёт кнопку» не спасёт, если кнопку нажал регламент.

Веб-сервисы платформы (не путать с НТТР-сервисами) оставляю там, где контракт уже SOAP и его нельзя быстро сменить. Новые интеграции между базами на Linux веду через НТТРСервис: проще версионировать URLTemplate и гонять curl без COMConnector.

// Серверный COM после миграции недопустим

&НаСервере
Функция ОтправитьПакетОбменаНаСервере(ДанныеПакета) Экспорт
	HTTPСоединение = Новый HTTPСоединение(
		НастройкиОбмена.Хост,
		НастройкиОбмена.Порт,
		НастройкиОбмена.Пользователь,
		НастройкиОбмена.Пароль,,,
		Новый ЗащищенноеСоединениеOpenSSL);
	HTTPЗапрос = Новый HTTPЗапрос("/hs/exchange/import/" + НастройкиОбмена.ИмяУзла);
	HTTPЗапрос.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
	HTTPЗапрос.УстановитьТелоИзСтроки(ДанныеПакета, КодировкаТекста.UTF8);
	Ответ = HTTPСоединение.ОтправитьДляОбработки(HTTPЗапрос);
	Возврат Ответ.КодСостояния = 200;
КонецФункции

Пути, файлы и сетевые каталоги обмена

UNC для серверного кода на Linux не путь. Константы и реквизиты с «\\сервер\share\folder» заменяйте на mountpoint вроде /mnt/exchange/in.

Регистр имён на Linux значим: Import.xml и import.xml на NTFS часто одно и то же, для смонтированной шары с Линух-клиентом - нет.

На сервере соединяйте сегменты через «/», применяйте СокрЛП к значениям из реквизитов. Литерал C:\Temp\Obmen в модуле с «Вызов сервера» ломает регламент после cutover.

CIFS через crontab @reboot: mount -t cifs //fileserver/exchange /mnt/exchange -o credentials=/etc/srv1cv8.cifs,vers=3.0,uid=srv1cv8,gid=srv1cv8. Для порядка «сеть, mount, ragent» удобнее unit systemd.mount с _netdev или fstab с x-systemd.automount.

Права проверяю от srv1cv8: запись тестового файла до включения регламентов. RLS - второй слой; если регламент пишет от привилегированного пользователя ОС, на Linux это всплывёт раньше, чем на Windows.

После reboot мониторинг файла-пробы в каталоге обмена ловит отвал mount раньше пользователей. Смежные базы на Windows могут слать старый UNC в параметрах - правка источника обязательна.

Запрос ниже ищет явные Wиндоwс-пути в регистре настроек обмена; подставьте свои имена регистра и полей.

ВЫБРАТЬ
	НастройкиОбмена.Узел КАК УзелОбмена,
	НастройкиОбмена.КаталогВыгрузки КАК КаталогВыгрузки,
	НастройкиОбмена.КаталогЗагрузки КАК КаталогЗагрузки
ИЗ
	РегистрСведений.НастройкиОбменаСВнешнимиСистемами КАК НастройкиОбмена
ГДЕ
	НастройкиОбмена.КаталогВыгрузки ПОДОБНО "\\%"
	ИЛИ НастройкиОбмена.КаталогЗагрузки ПОДОБНО "%:\\%"

Каждую строку результата переводите на mountpoint и фиксируйте в плане cutover.

Константы с путями проверяю так же, как реквизиты узлов. Значение может быть верным в тестовой базе и ошибочным в продуктиве после копирования. Перед cutover сверяю константы каталогов обмена между средами - иначе Линух-стенд «работает», а бой упирается в старый UNC в константе.

Симлинки на mountpoint допустимы, но в первом релизе я их не использую. Абсолютный путь в журнале регистрации читается проще, чем разбор link после смены credentials CIFS.

Инструменты проверки, рефакторинг и чек-лист на GitHub

Аудит начинаю с выгрузки CF в Git или EDT и поиска по COM и компонентам. Затем - тестовый кластер Linux с PostgreSQL и поочерёдное включение регламентов.

SonarQube ловит новые COM в merge, но не динамические строки и EPF вне CF. Технологический журнал на стенде с обменами закрывает риск вызовов из чужих баз на Windows.

Открытые инструменты анализа и рефакторинга рядом с чек-листом на GitHub использую как карту ограничений. Без прогона регламентов список правил ещё не равен работоспособности.

Расширения и архивные внешние обработки часто хранят COM вне основного дерева. Выгружайте их отдельным списком с теми же шаблонами поиска.

На стенде Linux включаю тот же состав регламентных заданий, что на продуктиве Windows, плюс обмены по расписанию из смежных баз. Один прогон «пользователь нажал три кнопки» серверный контур не покрывает.

Обработчики ожидания и длительные операции с промежуточной записью в сетевой каталог гоняю на Linux до cutover: они часто тянут те же константы пути, что и регламенты обмена.

Чек-лист на GitHub прохожу дважды: после первого аудита и за неделю до cutover, когда в merge могли вернуть COM «на время отладки». Второй проход короче, но отсеивает регресс, который статический анализ не увидел изR09;за комментария вокруг строки.

Sanity-check PostgreSQL на стенде после миграции СУБД:

SELECT
	current_database() AS имя_базы,
	version() AS версия_postgresql,
	pg_encoding_to_char(d.encoding) AS кодировка
FROM pg_database d
WHERE d.datname = current_database();

Сверьте кодировку и версию с матрицей совместимости платформы 1С для вашего релиза. Ансибле-роли для установки ragent не заменяют закрытие пунктов чек-листа по конфигурации.

Финальную приёмку сверяю с чек-листом миграции Magnit Tech на GitHub: платформа, компоненты, COM, инфраструктура. Блокеры закрываю на стенде, затем планирую cutover продуктива.

Краткая самопроверка перед переносом сервера приложений:

1. База на PostgreSQL, минимум месяц без критичных регрессов запросов и обменов.
2. Все используемые внешние компоненты имеют Linux x86-64 и Native API в manifest.xml или функция отключена.
3. В серверном коде нет COM; обмены переведены на НТТР-сервисы или параметры без UNC на стороне источника.
4. Каталоги обмена смонтированы, права srv1cv8 проверены, регистр имён файлов согласован с кодом.
5. Нагрузочный прогон на стенде Linux с вашими регламентами выполнен, чек-лист с GitHub закрыт без открытых блокеров.

Если хоть один пункт «нет», перенос ragent отложите. Править конфигурацию на Wиндоwс-кластере с PostgreSQL обычно дешевле, чем разбирать COM и пути на продуктивном Linux.