Я поддерживаю растущую базу в основном веб-приложений на основе Cocoon-2.1 [http://cocoon.apache.org/2.1/], развернутый в контейнере сервлетов Tomcat [http://tomcat.apache.org/]и проксируется с помощью http-сервера Apache [http://httpd.apache.org/docs/2.2/]. Я концептуально пытаюсь найти лучший способ развернуть несколько веб-приложений в Tomcat. Поскольку я не программист на Java и у нас нет штатных системных администраторов, я должен сам выяснить, как это сделать наиболее разумным способом. Моя установка развивалась по двум сценариям, и я рассматриваю третий для максимального разделения различных веб-приложений.
[1] 1 экземпляр Tomcat, 1 экземпляр Cocoon, несколько веб-приложений.
-tomcat
|_ webapps
|_ webapp1
|_ webapp2
|_ webapp[n]
|_ WEB-INF (with Cocoon libs)
Это был мой первый подход: просто поместите все веб-приложения в одну папку веб-приложений Cocoon внутри одного контейнера Tomcat. Кажется, все прошло нормально, проблем с памятью не возникло.
Однако это создает недостаток ремонтопригодности, поскольку некоторые компоненты Cocoon подлежат обновлению, что часто влияет на кодирование веб-приложений. Следовательно, обновление Cocoon становится громоздким: поскольку все веб-приложения используют один и тот же пул компонентов Cocoon, обновление одного из них потребует одновременного обновления кода во всех веб-приложениях.
Чтобы изолировать веб-приложения, я перешел ко второму сценарию.
[2] 1 экземпляр Tomcat, каждое веб-приложение в своей выделенной среде Cocoon.
-tomcat
|_ webapps
|_ webapp1
| |_ WEB-INF (with Cocoon libs)
|_ webapp1
| |_ WEB-INF (with Cocoon libs)
|_ webapp[n]
|_ WEB-INF (with Cocoon libs)
Этот подход разделяет все веб-приложения в их собственную среду Cocoon, запускаемую внутри одного контейнера Tomcat. Теоретически это работает нормально: все веб-приложения можно обновлять независимо.
Однако это вскоре приводит к ошибкам PermGenSpace. Казалось, что я смогу решить эту проблему, увеличив объем памяти для Tomcat, но я понимаю, что это не структурное решение, и что подобная перегрузка одного Tomcat может привести к ошибкам памяти в будущем.
Это заставило меня задуматься о третьем сценарии.
[3] несколько экземпляров Tomcat, каждый с одним веб-приложением в выделенной среде Cocoon.
-tomcat
|_ webapps
|_ webapp1
|_ WEB-INF (with Cocoon libs)
-tomcat
|_ webapps
|_ webapp2
|_ WEB-INF (with Cocoon libs)
-tomcat
|_ webapps
|_ webapp[n]
|_ WEB-INF (with Cocoon libs)
Я не пробовал этот подход, но думаю о переменной $ CATALINA_BASE. Один дистрибутив Tomcat может быть многократно инстанцирован с разными средами $ CATALINA_BASE, каждая из которых указывает на экземпляр Cocoon с собственным веб-приложением. Интересно, может ли такой подход избежать проблем подхода [2], связанных со структурной памятью, или же применимы те же проблемы?
С другой стороны, этот подход усложнил бы управление веб-интерфейсом Apache http, поскольку для этого потребуется, чтобы коннекторы AJP разных экземпляров Tomcat прослушивали разные порты. Следовательно, рабочая конфигурация Apache должна обновляться и перезагружаться всякий раз, когда добавляется новое веб-приложение (в его собственном экземпляре Tomcat). И, похоже, нет способа перезагрузить worker.properties без перезапуска всего http-сервера Apache.
Есть ли, возможно, другой / более динамичный способ «модулирования» нескольких веб-приложений, обслуживаемых Tomcat, или можно улучшить один из этих сценариев?
Любые мысли, предложения, советы очень ценятся.
Рон
Я сделал все, что вы упомянули, и на данный момент мы пошли в совершенно другом направлении. У нас есть образ виртуальной машины JEos, который мы используем с упрощенной виртуализированной ОС, и мы клонируем его для каждого нового приложения. Это не самый эффективный вариант с точки зрения памяти / процессора / диска, но избавляет меня от мысли о том, «к какому порту / каталогу все подключено».
По сути, СЕРВЕР определяет, какое приложение мы используем вместо порта / каталога /, что у вас есть.
Очевидно, это не сработает, если все, что у вас есть, - это одна машина или вы уже виртуализированы. В этом случае я бы рекомендовал общий CATALINA_BASE и указывал каждому новому приложению новый CATALINA_HOME. Соглашение о нумерации портов (например, 10) имеет большое значение для сохранения вашего рассудка в этом случае (поверьте мне).