Стратегия развертывания Tomcat

Question

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

В моей организации я вижу два типа развертывания.

1. Развертывание WAR в Tomcat webapps dir.Tomcat останавливается, существующий WAR-файл переименовывается, существующий каталог приложения в webapps ( appBase ) удаляется, новый WAR-файл копируется и Tomcat перезапускается.Плюс: развертывание WAR, похоже, понятно всем.Я вижу два недостатка:

   A. если WAR содержит информацию, относящуюся к развертыванию, такую ​​как информация о подключении к БД, среде разработки требуется какая-то версия и контроль сборки, чтобы убедиться, что правильная информация, относящаяся к развертыванию, поступает вфайл WAR.Это может усложниться.

   B. Много шагов, не сложно, но каждый шаг является потенциальной точкой ошибки.

2. appBase указывает на файловую систему приложенияинформация о развертывании хранится в другом месте.Развертываемая приложения файловая система или файл WAR копируются в папку на коробке Tomcat.Атрибут appBase для приложения в Tomcats Servlet.xml изменен, чтобы указывать на вновь развернутый код.Tomcat перезапускается после копирования.Вся информация о конфигурации развертывания хранится в отдельном каталоге в каталоге [tomcat_root], который не затрагивается развертыванием.Если требуются какие-либо изменения, они могут быть внесены в любое время, и Tomcat перезапустится, чтобы получить изменения.Плюс: очень простой, обычно только один шаг, максимум два шага. Минус: может потребоваться редактирование файла на компьютере развертывания.Это недопустимо во многих производственных средах или должно выполняться системным администратором, а не специалистом по развертыванию.Может привести к задержкам, политическим проблемам и указанию пальцем, если что-то пойдет не так.

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

Спасибо, - = b

Answer 1

Вот как я это делаю:

В контроле исходного кода у меня есть файлы свойств для каждой среды.Например, production-environment.properties, qa-environment.properties и т. Д. Все файлы свойств находятся в исходном каталоге resources и включены в файл WAR.

Tomcat запускается с системным свойством, которое выбираетокружение, например:

-Denvironment=production.

Приложение выбирает, какой файл свойств использовать во время выполнения, на основе системного свойства.

Никаких специальных шагов по сборке или развертыванию не требуется.Один файл WAR на сборку используется во всех средах.

Другим аспектом этого подхода является то, что свойства в файле WAR могут быть переопределены системными свойствами.Это позволяет ops изменять свойства после развертывания WAR.Кроме того, он позволяет полностью исключить конфиденциальную информацию, такую ​​как пароли базы данных, из системы контроля версий.

Answer 2

Я использую kwateeSDCM для автоматизации создания таких параметров, как информация о подключении к БД и развертывание на tomcat.Есть интересная статья в блоге, в которой говорится о развертывании войны на нескольких экземплярах tomcat .

Answer 3

Первым подходом можно управлять, автоматизируя процесс упаковки.Обычно я использую maven с профилями, предназначенными для разных сред развертывания.Инструмент сборки обеспечивает воспроизводимые сборки и предотвращает ваши ошибки.

В больших магазинах обычно есть большая китайская стена между dev и ops и выбирается второй подход.Разработчикам не разрешается трогать производственные серверы.