Мысли о том, как выполнить горячее развертывание с помощью JBoss 5

Я пытаюсь понять, возможно ли это. Сначала я расскажу вам о том, как в настоящее время работает приложение.

Приложение развертывается на 4 отдельных узлах (используя конфигурацию «все»). 2 узла на сервере ServerA и 2 узла на сервере B с именами node1, node2, node3, node4. Приложение находится за веб-сервером, на котором запущены apache и mod_jk для перенаправления трафика. Предположим, что в настоящее время развернута версия 1.0.0. Я попытаюсь развернуть версию 1.0.1, в которой будут лишь незначительные изменения.

Цель будет состоять в том, чтобы снять node4, развернуть версию 1.0.1 на node4 (пока node1-node3 все еще работает). Они будут использовать одну и ту же базу данных, что теоретически должно быть в порядке, если наш код не требует от нас обновления чего-либо в нашей базе данных. Следующим шагом будет направлять трафик с помощью apache + mod_jk только для балансировки нагрузки node1-node3. node4 будет доступен напрямую. node4 будет тестироваться под управлением версии 1.0.1. Apache + mod_jk будет изменен для обслуживания node4. Версия 1.0.1 будет развернута на node1-node3. Теперь все узлы должны работать под управлением версии 1.0.1.

Я знаю, что это чрезвычайно высокий уровень, и я уже сталкиваюсь с проблемами (не говоря уже о конкретных проблемах приложений).

Я просто хочу знать, какие есть другие способы решения этой или конкретных проблем JBoss, с которыми я могу столкнуться.

Должен ли я поместить узел горячего развертывания в другой кластер, а остальные подключиться позже?

Любые предложения помогут. Спасибо.


jboss hotdeploy jboss5.x
person leeman24    schedule 27.02.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы можете воспользоваться своим Apache с mod_jk впереди, представьте, что в вашей конфигурации есть что-то вроде:

JkMount  /myapp/* workerApp
JkWorkersFile /etc/httpd/conf/workerApp.properties

Что ж, вместо файла с именем workerApp.properties используйте эти 3 файла:

  • workerApp-deploy1.properties
    • Will contain configuration to connect only to node 4
  • workerApp-deploy2.properties
    • Will contain configuration to connect only to nodes 1,2 and 3
  • workerApp-normal.properties
    • This will be your actual workers file

Теперь wokerApp.properties является не файлом, а ссылкой, так что при обычных обстоятельствах:

ln -s workerApp-normal.properties workerApp.properties

При развертывании новой версии

rm -f workerApp.properties
ln -s workerApp-deploy2.properties workerApp.properties
reload apache

Теперь вы можете развернуть новую версию на узле 4, и все запросы будут проходить через узлы 1, 2 и 3. Когда развертывание на узле 4 будет готово:

rm -f workerApp.properties
ln -s workerApp-deploy1.properties workerApp.properties
reload apache

В этой ситуации все клиенты будут маршрутизатором на узле 4, и вы сможете обновить версии на других узлах. Когда вы закончите:

rm -f workerApp.properties
ln -s workerApp-normal.properties workerApp.properties
reload apache

И вы получаете баланс всех запросов между серверами.

У этого есть еще одно преимущество, например, вы можете определить VirtualHost, например preflighttest.yourcompany.com, используя другой набор рабочих процессов, чтобы вы могли протестировать свою новую версию на узле 4, прежде чем эффективно внедрять ее в производство.

Надеюсь, поможет.

person alphamikevictor    schedule 01.03.2015
comment
Спасибо за подробный ответ. Я обязательно включу это, чтобы сделать процесс чище для человека, который его запускает. Я, вероятно, воспользуюсь вашим советом, чтобы добавить vhost. Я думал, что бизнес-пользователи, тестирующие node4, просто получат доступ к приложению непосредственно через порт tomcat, но мне больше нравится идея vhost. Спасибо. - person leeman24; 02.03.2015
comment
Привет @alphamikevictor, я использовал метод символической ссылки, который будет довольно легко обернуть в скрипт. Спасибо еще раз. - person leeman24; 07.03.2015