← На главную

При работе с веб-сервером Apache в связке с платформой 1С:Предприятие часто возникает задача публикации нескольких информационных баз. Однако ситуация кардинально усложняется, когда эти базы требуют использования разных минорных или мажорных релизов платформы 1С. Рассмотрим, почему при попытке одновременной работы возникают ошибки вида HTTP: Unsupported media type или HTTP: Conflict, и как с этим справиться.

Разбор причин конфликта

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

Когда вы публикуете базу, в конфигурации Apache (файл httpd.conf или в директории conf.d) прописываются директивы LoadModule, указывающие на конкретную версию библиотеки wsap24.dll. Проблема в том, что внутри одного процесса Apache невозможно одновременно загрузить две разные версии этой библиотеки. Как только одна база пытается обратиться к своей версии платформы, а другая — к своей, возникает конфликт, который приводит к некорректной работе XDTO-сериализации и падению веб-клиента.

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

Самым надежным и архитектурно верным решением является полное разделение ресурсов. Мы не можем заставить один процесс Apache «понимать» две разные версии платформы 1С, поэтому нам нужно создать два отдельных веб-сервера.

1. Разнесение по портам: Настройте первый экземпляр Apache на стандартный порт 80, а второй — на альтернативный, например, 8080.
2. Конфигурация: Убедитесь, что каждый экземпляр веб-сервера ссылается на свою версию платформы 1С через соответствующие пути к модулям.
3. Изоляция процессов: Таким образом, каждый экземпляр Apache будет загружать в свою память только «свою» библиотеку wsap24.dll, что исключит любые конфликты версий.

Решение 2: Применение Reverse Proxy (Nginx)

Если вы хотите, чтобы для внешнего мира все базы выглядели как работающие на одном порту (например, 80 или 443), мы рекомендуем использовать архитектуру «обратного прокси». В этой схеме Nginx выступает в роли «фасада»:

1. Установите Nginx на сервер.
2. Настройте два независимых веб-сервера (это может быть два Apache или комбинация Apache и IIS), каждый из которых обслуживает свою версию платформы 1С на разных портах.
3. Настройте nginx.conf таким образом, чтобы входящие запросы к определенным URL перенаправлялись на соответствующий внутренний порт:
   Скопировать код

   
   location /base1 {
       proxy_pass http://127.0.0.1:8080;
   }
   location /base2 {
       proxy_pass http://127.0.0.1:8081;
   }
   

Этот подход является современным стандартом в IT-инфраструктуре, так как он обеспечивает масштабируемость и полную независимость настроек для каждой информационной базы.

Решение 3: Контейнеризация (Docker)

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

Преимущества контейнеризации:

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

Подводим итоги

Попытка «подружить» разные версии платформы 1С внутри одного экземпляра Apache — это тупиковый путь, ведущий к ошибкам XDTO и проблемам с Unsupported media type. Чтобы система работала стабильно, мы должны обеспечить физическое разделение процессов веб-сервера либо через разные порты, либо через прокси-серверы, либо через контейнеры.

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