Как настроить Apache для работы с несколькими версиями платформы 1С на одном веб-сервере?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При попытке разместить несколько информационных баз 1С, работающих на разных версиях платформы, на одном веб-сервере Apache, пользователи часто сталкиваются с проблемой. Давайте рассмотрим эту ситуацию подробнее и выясним, какие решения существуют для её преодоления. Также полезно иметь под рукой общую справку по задачам администрирования Windows, Linux и 1С.

Суть проблемы: конфликт имен модулей 1С в Apache

Основная причина сложностей заключается в том, что веб-модуль 1С для Apache (например, файл wsap24.dll для Windows или wsap24.so для Linux) имеет одно и то же внутреннее имя для разных версий платформы 1С. Веб-сервер Apache, по своей архитектуре, не может одновременно загрузить несколько модулей с идентичными внутренними именами, даже если они расположены по разным файловым путям. При попытке загрузки нескольких таких модулей Apache загрузит только первый, который найдет, и будет использовать его из кеша. Это приводит к ошибкам несоответствия версий клиента и сервера 1С при попытке доступа к базам, опубликованным под другими версиями платформы.

Важно понимать: это ограничение подтверждено разработчиками Apache и не будет исправляться в обозримом будущем. Таким образом, нам необходимо искать обходные пути и альтернативные решения.

Решение 1: Использование нескольких экземпляров Apache

Если для нас принципиально использовать веб-сервер Apache, наиболее распространенным и эффективным обходным путем является установка и настройка нескольких его экземпляров. Каждая версия платформы 1С будет обслуживаться своим собственным, независимым экземпляром Apache.

  1. Установка отдельных экземпляров Apache:

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

    • C:\Apache24_8.3.10 для версии 8.3.10
    • C:\Apache24_8.3.11 для версии 8.3.11
    • и так далее.

    Каждый из этих каталогов будет содержать полный набор файлов Apache, включая свой собственный конфигурационный файл httpd.conf.

  2. Настройка конфигурационных файлов (httpd.conf) для каждого экземпляра:

    В конфигурационном файле каждого экземпляра Apache необходимо внести следующие изменения:

    • Уникальный порт прослушивания (Listen): Каждый экземпляр Apache должен прослушивать свой уникальный порт, чтобы избежать конфликтов. Например: 
      
Listen 127.0.0.1:80
Listen 127.0.0.1:81
Listen 127.0.0.1:82

      Мы выбираем свободные порты для каждого экземпляра.

    • Путь к модулю 1С (LoadModule _1cws_module): Для каждого экземпляра Apache указываем путь к файлу веб-модуля 1С (wsap24.dll или wsap24.so), который соответствует версии платформы 1С, которую будет обслуживать именно этот экземпляр Apache. 
      
LoadModule _1cws_module "C:/Program Files (x86)/1cv8/8.3.10.2299/bin/wsap24.dll"
LoadModule _1cws_module "C:/Program Files (x86)/1cv8/8.3.11.3034/bin/wsap24.dll"
    • Корневой каталог сервера (ServerRoot): Убеждаемся, что директива ServerRoot указывает на корневую директорию соответствующего экземпляра Apache.
  3. Регистрация каждого экземпляра Apache как отдельной службы:

    В операционной системе Windows мы регистрируем каждый настроенный экземпляр Apache как отдельную службу. Это позволяет им работать параллельно и независимо друг от друга. Используем командную строку (от имени администратора):

    
"C:\Apache24_8.3.10\bin\httpd.exe" -k install -n "Apache2.4_1CV8.3.10" -f "C:\Apache24_8.3.10\conf\httpd.conf"
"C:\Apache24_8.3.11\bin\httpd.exe" -k install -n "Apache2.4_1CV8.3.11" -f "C:\Apache24_8.3.11\conf\httpd.conf"

    Обратите внимание: параметр -n задает уникальное имя службы, а -f указывает путь к конкретному конфигурационному файлу для этой службы.

    В Linux аналогично настраиваются отдельные systemd-службы или скрипты инициализации для каждого экземпляра Apache. При настройке служб в Linux полезно знать, как организовать "кошерный" перезапуск сервера с очисткой данных.

  4. Публикация информационных баз:

    При публикации информационных баз 1С через Конфигуратор или консольную утилиту webinst, критически важно использовать версию утилиты, соответствующую версии платформы, и указывать правильный порт и путь к конфигурационному файлу Apache, который мы настроили для этой версии. Если мы используем утилиту webinst, ее путь также должен соответствовать версии платформы 1С (например, C:\Program Files (x86)\1cv8\8.3.10.2299\bin\webinst.exe).

  5. Упрощение управления конфигурациями с помощью переменных и включаемых файлов:

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

    Пример использования переменных (по аналогии с сообщениями 12 и 14):

    Создаем основной конфигурационный файл, например, conf/httpd_common.conf, где будут общие настройки. Затем, для каждой версии Apache, создаем свой небольшой конфигурационный файл, например, conf/httpd_8.3.10.conf и conf/httpd_8.3.11.conf. В этих файлах мы можем определить переменные для версии 1С:

    
# Пример файла conf/httpd_8.3.10.conf
Define OneCVer 10
Define OneCVerFull 8.3.10.2299
ServerRoot "C:/Apache24_8.3.10"
Listen 127.0.0.1:80
LoadModule _1cws_module "C:/Program Files/1cv8/${OneCVerFull}/bin/wsap24.dll"
Include conf/httpd_common.conf

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

    Пример, вдохновленный сообщением 13, демонстрирует, как включить общий файл: 

    
ServerRoot "C:/Program Files (x86)/Apache Software Foundation/Apache2.4_8.3.10.2505"
Listen 127.0.0.1:81
LoadModule _1cws_module "C:/Program Files (x86)/1cv8/8.3.10.2505/bin/wsap24.dll"
Include "../conf/httpd_common.conf"

    В этом случае, все общие настройки (например, директивы, касающиеся логирования, виртуальных хостов, или общих правил безопасности) будут находиться в httpd_common.conf, а уникальные для каждого экземпляра Apache параметры (ServerRoot, Listen, LoadModule) — в его индивидуальном конфигурационном файле.

Решение 2: Использование веб-сервера IIS (Internet Information Services)

Веб-сервер IIS от Microsoft является более гибким в плане работы с несколькими версиями модулей расширения, таких как модули 1С (обычно wsisapi.dll, но иногда можно использовать и wsap24.dll в режиме ISAPI). Хотя существуют и альтернативные подходы к обработке HTTP-запросов в 1С.

  1. Создание отдельных пулов приложений (Application Pools):

    В IIS мы создаем отдельный пул приложений для каждой версии платформы 1С. Это позволяет изолировать процессы и библиотеки разных версий друг от друга.

  2. Настройка ISAPI Restrictions:

    Необходимо зарегистрировать все используемые версии wsisapi.dll (или wsap24.dll, если это требуется для вашего сценария) в разделе "Ограничения ISAPI" (ISAPI Restrictions) в IIS и разрешить их выполнение.

  3. Назначение публикаций пулам приложений:

    Для каждой публикации информационной базы 1С в IIS мы указываем необходимую версию веб-расширения и соответствующий ей пул приложений.

    Важный аспект: в рамках одного пула приложений должны работать только расширения одной версии 1С, и разрядность библиотек (32-бит или 64-бит) должна совпадать с разрядностью пула приложений. Если нам нужно запустить 32-разрядное приложение 1С на 64-разрядном IIS, для соответствующего пула приложений потребуется включить опцию "Разрешить 32-разрядные приложения".

  4. Особенности публикации:

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

Решение 3: Виртуализация и контейнеризация (Docker)

Использование технологий виртуализации или контейнеризации является мощным решением для изоляции различных версий 1С, особенно актуальным для среды Linux, но применимым и в Windows.

  1. Применение Docker:

    Docker позволяет нам развернуть каждую версию платформы 1С в отдельном, изолированном контейнере. Каждый такой контейнер будет иметь свой собственный веб-сервер Apache (или Nginx) и соответствующую версию веб-модуля 1С, работающую на своем уникальном порту.

    Преимущества:

    • Изоляция: Полностью устраняются конфликты модулей, так как каждая версия работает в своей собственной изолированной среде.
    • Переносимость: Контейнеры легко переносить между разными серверами, обеспечивая единообразную среду развертывания.
    • Управляемость: Управление различными версиями становится более структурированным и менее подверженным ошибкам.

Решение 4: Использование обратного прокси (Nginx или еще один Apache)

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

  1. Настройка "внешнего" прокси-сервера:

    Мы устанавливаем и настраиваем один "внешний" веб-сервер (Nginx или Apache), который будет прослушивать стандартные порты (например, 80 и 443). Этот сервер будет являться единственной точкой входа для всех запросов.

  2. Перенаправление запросов:

    Обратный прокси-сервер настраивается для перенаправления (проксирования) запросов к соответствующим "внутренним" экземплярам Apache или IIS, которые мы уже настроили для разных версий 1С и которые прослушивают свои уникальные порты. Маршрутизация может осуществляться на основе различных правил:

    • По префиксу URL: Например, запросы к http://localhost/SuperV10 могут перенаправляться на http://localhost:81/SuperV10 (где 81 — порт Apache для версии 8.3.10), а запросы к http://localhost/SuperV11 — на http://localhost:82/SuperV11 (порт для версии 8.3.11).
    • По имени хоста: Запросы к http://v8310.mysite.com могут идти на один внутренний сервер, а к http://v8311.mysite.com — на другой.

    Пример конфигурации Nginx (фрагмент):

    
server {
    listen 80;
    server_name my1c.com;

    location /v8310/ {
        proxy_pass http://localhost:81/v8310/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /v8311/ {
        proxy_pass http://localhost:82/v8311/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

    Таким образом, для пользователей все публикации выглядят так, будто они доступны на одном сервере через стандартный порт, что значительно упрощает доступ и управление ссылками.

  3. Преимущества обратного прокси:
    • Единая точка входа: Пользователям не нужно запоминать разные порты.
    • Централизация SSL: Мы можем управлять SSL-сертификатами и шифрованием на одном прокси-сервере, а внутренние соединения могут быть по HTTP.
    • Безопасность: Прокси может служить дополнительным уровнем защиты.
    • Балансировка нагрузки: При необходимости, прокси может распределять запросы между несколькими бэкенд-серверами.

Общие рекомендации при работе с веб-сервером 1С

Вне зависимости от выбранного метода, есть несколько общих рекомендаций, которые помогут нам в работе:

  1. Согласование разрядности: Всегда следим за тем, чтобы разрядность веб-сервера (Apache или IIS) и используемого модуля 1С совпадала. Если у нас 64-разрядный Apache, то и модуль wsap24.dll должен быть 64-разрядным, и, соответственно, платформа 1С, под которой он работает, также должна быть 64-разрядной. Аналогично для 32-разрядных версий.
  2. Размещение серверов: Веб-сервер и сервер 1С могут быть установлены на разных физических или виртуальных машинах. Однако для их корректного взаимодействия мы должны обеспечить надежную сетевую связность между ними.
  3. Использование утилиты webinst: Помимо публикации баз через Конфигуратор 1С, мы можем использовать консольную утилиту webinst (например, C:\Program Files (x86)\1cv8\8.3.10.2299\bin\webinst.exe). Эта утилита позволяет публиковать информационные базы без необходимости наличия клиентской лицензии 1С и может быть полезна для автоматизации или в случаях, когда Конфигуратор ведет себя непредсказуемо с настройками веб-сервера.

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

← На главную