Публикация баз 1С на веб-сервере: IIS и Apache без мифов

Публикация базы выглядит как три клика в конфигураторе. Клики действительно три, а вот вопросов после них — десяток: почему браузер отдаёт 404, куда делся OData, почему на HTTPS всё встало и отчего публикация исчезла после обновления платформы. Разберём механику по шагам, чтобы ошибки перестали быть загадочными.

Конфигуратор не «выкладывает базу в интернет». Он делает две вещи: создаёт каталог с файлом описания и прописывает в веб-сервер путь к модулю расширения.

Модуль — это wsisapi.dll для IIS и wsap24.dll для Apache 2.4. Живут они в каталоге bin установленной платформы. Именно они принимают HTTP-запрос и транслируют его в вызов кластера 1С.

Файл описания — default.vrd. Он лежит в каталоге публикации и содержит буквально всё, что важно:

<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/buh"
       ib="Srvr=&quot;SRV-1C&quot;;Ref=&quot;buh_prod&quot;;">
  <standardOdata enable="true" reuseSessions="autouse"
                 sessionMaxAge="20" poolSize="10" poolTimeout="5"/>
</point>

Отсюда сразу три вывода. Первый: перенести публикацию на другой сервер = скопировать каталог и поправить Srvr. Второй: включить OData можно правкой одной строки, конфигуратор для этого не обязателен. Третий: если в ib прописан пользователь и пароль открытым текстом — а мастер публикации это умеет — файл становится хранилищем учётных данных, и права на каталог надо смотреть внимательно.

На IIS публикация 1С почти всегда упирается в одно из трёх мест.

Разрядность пула. Платформа x64 требует пула без поддержки 32-битных приложений. Если в свойствах пула стоит Enable 32-Bit Applications = True, а модуль 64-битный, IIS вернёт 500.0 с внутренним кодом 0x8007000b. Симптом узнаваемый: в браузере пустая страница ошибки, в журнале приложений тишина.

Учётная запись пула. По умолчанию пул работает от ApplicationPoolIdentity — виртуальной учётки без прав в домене. Она не сможет обратиться к кластеру 1С, если тот требует доменной аутентификации, и не прочитает сетевые каталоги. Мы переводим пул на ту же сервисную учётку, под которой живёт сервер 1С, либо на отдельную svc_1cweb с правом на каталог публикации.

Обработчик и ISAPI. Роль веб-сервера должна включать ISAPI Extensions и ISAPI Filters. Без них модуль просто не подключится, а IIS отдаст 404.3 — «расширение не настроено». Эта ошибка обманчива: путь правильный, файл на месте, но обработчика нет.

Install-WindowsFeature Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Windows-Auth
Set-ItemProperty "IIS:\AppPools\1CWeb" -Name enable32BitAppOnWin64 -Value $false

После правок пул перезапускаем. IIS кэширует конфигурацию агрессивнее, чем кажется.

Apache под Windows для 1С ставят реже, но на Linux-серверах он основной вариант. Публикация делается утилитой webinst из состава платформы.

/opt/1cv8/x86_64/8.3.24.1234/webinst -apache24 \
  -wsdir buh -dir /var/www/buh \
  -connstr "Srvr=srv-1c;Ref=buh_prod;" \
  -confPath /etc/apache2/apache2.conf

Утилита дописывает в конфиг Apache блок LoadModule _1cws_module и Alias. Дальше начинается специфика.

Права. Каталог публикации должен читаться пользователем www-data, а сам процесс Apache — иметь доступ к каталогу платформы. Классическая ошибка: webinst отработал от root, каталог создан с правами root:root, Apache падает в 403.

SELinux на RHEL-подобных системах блокирует загрузку модуля из /opt. Симптом — Apache не стартует вообще, в audit.log запись про module_load. Лечится контекстом, а не выключением SELinux целиком.

И ещё: после обновления платформы путь в LoadModule продолжает указывать на старую версию. Apache стартует, публикация отдаёт 500. Нужно править вручную либо перепубликовывать. Это же справедливо и для IIS — там путь к wsisapi.dll живёт в обработчике сайта.

Опубликованная база по HTTP — это логин и пароль пользователя 1С открытым текстом в каждом запросе. Даже внутри локальной сети это плохая идея, а наружу — недопустимая.

Схема, которую мы ставим клиентам: снаружи стоит обратный прокси (nginx либо тот же IIS с ARR) с сертификатом Let's Encrypt, внутрь идёт HTTP на адрес веб-сервера 1С, который слушает только внутренний интерфейс.

Что даёт прокси кроме шифрования: ограничение скорости запросов, фильтрацию по IP для административных путей, нормальные журналы доступа и возможность выключить публикацию одной строкой, не трогая 1С.

Отдельно — про доступ к /odata. Этот путь отдаёт данные напрямую и обычно нужен одной-двум интеграциям с известных адресов. Мы закрываем его на прокси и открываем адресно:

location /buh/odata/ {
    allow 10.10.10.0/24;
    allow 93.95.102.150;
    deny all;
    proxy_pass http://127.0.0.1:8080;
}

Публиковать веб-клиент для сотрудников и оставлять при этом открытый OData — распространённая и дорогая ошибка. Первый требует логина в интерфейсе, второй прекрасно отдаётся скриптом.

Публикация открывает сразу несколько каналов доступа, и путаница между ними порождает половину вопросов на поддержке.

Веб-клиент работает прямо в браузере. Ставить ничего не нужно, но и возможности урезаны: нет работы со сканером, ограничена работа с файловой системой, печать идёт через браузер. Для бухгалтера, который весь день сидит в документах, вариант так себе. Для руководителя, которому раз в неделю нужно посмотреть отчёт с планшета, — идеальный.

Тонкий клиент через веб-сервер — недооценённый режим. Пользователь запускает привычное приложение 1С, но соединение идёт не по протоколу кластера, а по HTTP через ту же публикацию. Полная функциональность плюс возможность работать из-за NAT без VPN. Именно этот вариант мы чаще всего предлагаем филиалам: адрес базы в списке выглядит как https://1c.example.ru/buh, и всё.

Разница по трафику заметная. На типовой операции проведения документа тонкий клиент по HTTP передаёт в два-три раза меньше данных, чем веб-клиент, — просто потому, что не гоняет разметку интерфейса. На канале 10 Мбит с задержкой 40 мс это ощущается сразу.

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

Практика: мы почти всегда публикуем базу один раз, а дальше выдаём пользователям нужный способ подключения. Плодить три публикации на одну базу не нужно — default.vrd обслуживает все режимы сразу.

Порядок диагностики у нас всегда одинаковый: сначала проверяем, что тонкий клиент вообще подключается к кластеру напрямую. Если нет — проблема не в публикации. Потом смотрим журнал веб-сервера, а не браузер: браузер показывает обобщённую страницу, журнал — конкретный подкод.

Публикация — самый хрупкий элемент связки. Она переживает перезагрузку, но плохо переживает изменения вокруг себя.

• Обновление платформы 1С. Модуль меняет путь. Перепубликовать или поправить руками. Мы добавили этот пункт в регламент обновления платформы после того, как у клиента веб-доступ отвалился на трое суток — обновили ночью, а пользуются веб-клиентом только в филиале, и заметили не сразу.
• Переименование сервера. В default.vrd имя сервера прописано строкой. Переименовали — правьте файл.
• Смена пароля сервисной учётки. Пул IIS останавливается. Событие 5021 в системном журнале.
• Обновление Windows с накатом IIS. Иногда сбрасывает настройки разрядности пула.

Практическая рекомендация: держите рядом с каталогом публикации текстовый файл с датой публикации, версией платформы и адресом кластера. Стоит минуту, а при разборе через год экономит час.

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

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

Веб-сервер сам по себе почти ничего не считает — он транслирует запросы в кластер. Упирается всё обычно не в него. Но пара мест, где именно публикация становится узким горлом, есть.

Первое — размер пула соединений OData. Параметр poolSize в default.vrd по умолчанию небольшой, и активная интеграция легко его выбирает. Симптом: запросы к OData начинают ждать по несколько секунд, при этом веб-клиент летает. Увеличиваем до 20–30 и следим за памятью кластера.

Второе — время жизни сеанса, sessionMaxAge. Значение в минутах. Слишком маленькое заставляет каждый запрос поднимать новый сеанс 1С, а это дорого: сеанс — не бесплатная сущность, он занимает лицензию и память. Слишком большое копит мёртвые сеансы. Для интеграции, которая ходит раз в минуту, разумно 20; для редких обращений — 5.

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

Проверить, сколько сеансов реально держит публикация, проще всего из консоли кластера: в списке сеансов у веб-подключений в колонке приложения будет значиться веб-клиент или тонкий клиент, а в колонке компьютера — адрес веб-сервера, а не рабочей станции. Это, кстати, неприятный побочный эффект: все веб-сеансы выглядят пришедшими с одной машины, и по журналу регистрации сложно понять, кто откуда работал.

Что быстрее для 1С — IIS или Apache?

Разницы в скорости на нагрузке офиса до 50 человек практически нет; узкое место находится в кластере и СУБД, а не в веб-сервере. Выбирайте по платформе: на Windows проще IIS, на Linux — Apache.

Можно ли включить OData без конфигуратора?

Да. Достаточно в файле default.vrd выставить у элемента standardOdata атрибут enable в true и перезапустить пул приложений. Не забудьте, что в самой конфигурации нужные объекты должны быть включены в состав REST-интерфейса.

Почему после обновления платформы веб-клиент отдаёт 500?

Обработчик веб-сервера продолжает ссылаться на модуль из каталога старой версии платформы, которого больше нет. Нужно перепубликовать базу либо поправить путь к wsisapi.dll или wsap24.dll вручную.

Обязателен ли обратный прокси, если публикация только внутри сети?

Не обязателен, но HTTPS нужен всё равно: без него пароли пользователей 1С ходят по сети открытым текстом. Прокси при этом сильно упрощает выдачу сертификата и ведение журналов доступа.