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

← На главную

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

Выясняем причину: почему нельзя опубликовать разные версии 1С в одном экземпляре Apache?

Для начала разберем внутреннюю архитектуру взаимодействия 1С с веб-сервером. Публикация информационной базы на Apache происходит за счет подключения специального модуля расширения — динамической библиотеки. В зависимости от версии веб-сервера это может быть файл wsap24.dll для Apache 2.4 или wsap22.dll для Apache 2.2. Этот модуль загружается в адресное пространство процесса веб-сервера при его старте.

Ключевое ограничение архитектуры заключается в том, что в рамках одного запущенного процесса веб-сервера невозможно одновременно загрузить две разные версии одной и той же динамической библиотеки. Если мы попытаемся прописать в конфигурационном файле одного экземпляра Apache пути к библиотекам версий 1С 8.3.10 и 8.3.14, веб-сервер загрузит только ту библиотеку, которая была объявлена первой. При попытке пользователя зайти в базу другой версии произойдет критическая ошибка несоответствия версий клиента и сервера. Выражается она в виде системного сообщения: HTTP: Conflict / Различаются версии клиента и сервера.

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

Решение проблемы по шагам: настройка нескольких служб Apache без копирования папок веб-сервера

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

Выполним настройку по шагам:

Переходим в рабочий каталог установленного веб-сервера Apache. Обычно конфигурационные файлы располагаются по пути C:\Apache24\conf\. Нам необходимо создать два отдельных конфигурационных файла под наши версии платформ. Назовем их, к примеру, httpd_8310.conf и httpd_8314.conf.
Открываем первый конфигурационный файл httpd_8310.conf в текстовом редакторе. Нам нужно настроить сетевой порт, который будет слушать этот экземпляр, и указать путь к соответствующей библиотеке 1С. Находим директиву Listen и задаем свободный порт, например: Listen 8080 Затем в конце файла или в блоке загрузки модулей прописываем путь к модулю расширения веб-сервера версии 8.3.10.2561: LoadModule _1cws_module "C:/Program Files/1cv8/8.3.10.2561/bin/wsap24.dll"
Открываем второй конфигурационный файл httpd_8314.conf. Здесь мы должны указать другой сетевой порт. Обратите внимание, что выбор порта очень важен. Часто используемый разработчиками порт 8081 может быть занят другими системными процессами или защитным ПО, что вызывает ошибку инициализации сокетов. Рекомендуем использовать порты из свободного диапазона, например, порт 8888. Прописываем директиву прослушивания: Listen 8888 Далее указываем путь к модулю расширения веб-сервера версии 8.3.14.1779: LoadModule _1cws_module "C:/Program Files/1cv8/8.3.14.1779/bin/wsap24.dll"
Теперь нам нужно зарегистрировать две новые службы Windows. Для этого запускаем командную строку от имени администратора, переходим в каталог с исполняемым файлом Apache (например, C:\Apache24\bin) и выполняем две команды установки служб с явным указанием имени службы и пути к файлу конфигурации через ключ -f:
```
httpd.exe -k install -n "Apache_1C_8.3.10" -f "C:/Apache24/conf/httpd_8310.conf"
httpd.exe -k install -n "Apache_1C_8.3.14" -f "C:/Apache24/conf/httpd_8314.conf"
```
После успешного выполнения команд в оснастке "Службы" операционной системы появятся две новые службы с именами Apache_1C_8.3.10 и Apache_1C_8.3.14. Запускаем их.

Теперь базы данных 1С версии 8.3.10 будут доступны пользователям по сетевому адресу с указанием порта 8080 (например, http://имя_сервера:8080/имя_базы), а базы версии 8.3.14 — по порту 8888 (например, http://имя_сервера:8888/имя_базы). Процессы веб-серверов полностью изолированы и не конфликтуют.

Анализируем возможные ошибки при запуске служб

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


AH00072: make_sock: could not bind to address 0.0.0.0:8081
AH00451: no listening sockets available, shutting down

Эта ошибка однозначно указывает на то, что веб-сервер Apache не смог занять указанный сетевой порт (в данном случае 8081). Выясним причину этой ситуации. Порт 8081 часто используется различными прокси-серверами, антивирусным программным обеспечением, системами мониторинга или другими веб-службами. Если порт уже занят другим процессом в операционной системе, Apache не сможет открыть сокет для прослушивания входящих подключений и аварийно завершит свою работу.

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

netstat -ano | findstr 8081

В выводе команды мы увидим идентификатор процесса (PID), который занимает порт. После этого мы сможем завершить процесс или изменить его настройки. Второй, более простой и надежный путь в условиях реального производства — использовать для второго экземпляра веб-сервера заведомо свободный порт, например 8888 или 8090, в конфигурационном файле службы.

Альтернативный подход: почему использование веб-сервера IIS может быть проще?

Если сервер работает под управлением операционной системы Windows Server, хорошей альтернативой Apache является встроенный веб-сервер IIS (Internet Information Services). Многие специалисты рекомендуют использовать именно его для работы с несколькими версиями платформы 1С, так как его архитектура изначально ориентирована на изоляцию процессов.

В IIS существует понятие пулов приложений (Application Pools). Пул приложений — это изолированная рабочая среда, в которой запускаются веб-ресурсы. Каждый пул работает в рамках собственного системного процесса w3wp.exe. Это означает, что мы можем настроить изоляцию без создания дополнительных системных служб и без необходимости выделять под каждую версию платформы отдельный сетевой порт. Все базы смогут работать на стандартных портах 80 (HTTP) и 443 (HTTPS).

Проанализируем общую схему настройки на IIS:

Открываем Диспетчер служб IIS и переходим в раздел "Пулы приложений". Создаем два новых пула: Pool_1C_8.3.10 и Pool_1C_8.3.14.
Переходим в раздел "Ограничения ISAPI и CGI" на уровне всего веб-сервера. Нам необходимо зарегистрировать библиотеки wsisapi.dll от обеих версий платформ 1С и разрешить их выполнение.
Создаем виртуальные каталоги для наших баз 1С. При создании или в свойствах уже созданного приложения принудительно сопоставляем его с нужным пулом приложений. Базы на платформе 8.3.10 привязываем к пулу Pool_1C_8.3.10, а базы на платформе 8.3.14 — к пулу Pool_1C_8.3.14.
В настройках "Сопоставление обработчиков" для каждого конкретного виртуального каталога указываем путь к библиотеке wsisapi.dll соответствующей версии платформы.

За счет изоляции рабочих процессов пулов приложений библиотеки wsisapi.dll разных версий будут загружены в память в рамках разных процессов w3wp.exe и не будут конфликтовать между собой. При этом пользователи будут обращаться к базам по привычным адресам без указания специфических портов в браузере или в тонком клиенте 1С.

Современный production-подход: использование связки Nginx + Apache

Если использование IIS невозможно (например, сервер работает под управлением Linux) или вы принципиально хотите использовать веб-сервер Apache, работа пользователей на разных нестандартных портах (таких как 8080 или 8888) может вызвать ряд неудобств. Пользователям сложно запоминать порты, системным администраторам приходится открывать дополнительные порты в брандмауэрах компании, а настройка шифрования данных SSL/TLS (HTTPS) для каждого отдельного экземпляра Apache превращается в трудоемкую задачу.

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

Рассмотрим подробнее схему работы такой связки:

На сервере устанавливается веб-сервер Nginx, который принимает все входящие запросы от пользователей на стандартных портах 80 (HTTP) и 443 (HTTPS).
Настраиваются локальные экземпляры Apache для версий платформ 8.3.10 и 8.3.14 (как мы разбирали во втором разделе). Однако мы закрываем их порты от внешнего доступа и настраиваем их на прослушивание только локального адреса (127.0.0.1:8080 и 127.0.0.1:8888 соответственно).

В конфигурационном файле Nginx настраиваются правила перенаправления запросов в зависимости от URL обращения. Разберем пример конфигурационного файла Nginx:


server {
    listen 443 ssl;
    server_name 1c.company.ru;

    ssl_certificate /etc/ssl/certs/1c_company.crt;
    ssl_certificate_key /etc/ssl/certs/1c_company.key;

    # Перенаправление запросов для баз версии 8.3.10
    location /base_old/ {
        proxy_pass http://127.0.0.1:8080/base_old/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # Перенаправление запросов для баз версии 8.3.14
    location /base_new/ {
        proxy_pass http://127.0.0.1:8888/base_new/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Преимущества такой архитектуры очевидны: все пользователи работают по защищенному протоколу HTTPS через стандартный порт 443. SSL-сертификат настраивается и обновляется в одном месте — на Nginx. Сам Nginx работает очень быстро и эффективно распределяет нагрузку, пересылая запросы на локальные инстансы Apache, которые занимаются исключительно обработкой логики расширений 1С.