У нас есть производственная среда с внешне сбалансированными серверами Tomcat, работающими на нескольких серверах, обслуживающих HTTP-запросы и поддерживающих сеансы накопителя.
Из-за отсутствия полного процесса сборки и развертывания (к сожалению, я не вижу, чтобы это произошло в ближайшем будущем!), Существует команда Ops, которая отвечает за копирование JSP / классов / статических ресурсов / файлов свойств или даже за изменение распорок. config.xml (иногда web.xml!) вручную. Мы не строим ВОЙНЫ !!
Поскольку это интенсивная ручная работа, человеческая ошибка создает множество проблем, потому что одни и те же шаги должны выполняться в нескольких средах (в день развертывания это может быть как минимум около 10 машин), что делает отладку даже сложной.
Я понимаю, что мы далеки от идеальной производственной среды (в этом отношении даже практической производственной среды), но я просто провел мозговой штурм и подумал, что, если мы можем установить (скопировать) Tomcat в высокоскоростной SAN и смонтировать его как общий диск на каждом server, чтобы по крайней мере изменения коснулись всех узлов одновременно.
Пожалуйста, дайте мне знать ваши мысли и особенно критику в отношении этого подхода.
Спасибо.
Хотя можно совместно использовать некоторые каталоги в развертывании Tomcat (см. этот вопрос), делиться теми, которыми вы хотите поделиться, небезопасно, и хотя это может сработать, если вы позаботитесь о локализации каталогов ./work и ./temp, вы просите о трудных для устранения проблем, если вы пробуете это, не говоря уже о создании единой точки отказа в вашей инфраструктуре.
Мне, как разработчику / оператору, посчастливилось работать в тесном сотрудничестве с моими разработчиками, и я придумал автоматическое развертывание для ряда очень сложных и беспорядочных приложений. Мой совет в этой области заключается в том, что, если вы можете заставить свою команду согласиться с целью автоматизации развертывания, просто начните с малого и автоматизируйте немного больше на каждой итерации, поскольку ваша команда разработчиков и команда операторов привыкнут к процессу и проработать петли.
Для моей рекомендации по вашей конкретной проблеме здесь, если можно будет смонтировать один общий диск на ваших производственных машинах, лучшим решением, вероятно, будет сохранение канонического образа вашей настройки tomcat на общем диске, а затем запись некоторые (могут быть очень простые) сценарии для обновления всех или части развернутых котов на каждом сервере приложений при внесении изменений. Это упростит постепенное развертывание изменений (если вы это сделаете), отмените изменения, которые не работают, и убедитесь, что все синхронизировано на всех серверах приложений.
Если бы ваши разработчики могли получить доступ на запись к этому общему диску, вы могли бы даже помочь специалистам по эксплуатации, убрав у них процесс редактирования, подверженный ошибкам, и просто попросив их развернуть определенные файлы или каталоги. После того, как у вас есть эта инфраструктура и процесс, вы можете приступить к автоматизации: разработчики могут писать сценарии автоматизации и сохранять их на общем диске, чтобы операторы могли запускать их и строить оттуда.
Вы не хотите этого делать, он может перенести все сразу, регистрация будет сложной, а откаты будут беспорядочными. Используйте камень убийства, чтобы распознать это.
Мне не нравится tomcat, но, возможно, я могу поделиться тем, что я делаю для аналогичной задачи:
Просто подготовьте папку со всеми обновлениями (например, у меня seed12/etc/apache2/apache2.conf и seed12/var/www/index.php) - только те файлы, которые вы обновляете, помещенные в соответствующие папки, всегда начиная с корня.
Затем сделайте простой скрипт, который scp -r к каждой машине. Вы можете добавить в сценарий некоторые команды ssh для перезапуска ваших служб, если это необходимо.
Дополнительным преимуществом является то, что он отчасти самодокументируется - просто сохраняйте эти «исходные» папки и, таким образом, регистрируйте все изменения.
Что касается критики (вы спросили!) К вашему подходу - она добавляет ненужную точку отказа в вашу избыточную установку.