Если вам удалось прочесть мой последний блог, вы вспомните, что я продемонстрировал простой скрипт для создания новой установки tomcat на сервере путем разделения двоичных файлов tomcat из файлов conf, сохранения двоичных файлов на FTP-сервере и файлов conf в версии контроль, с помощью сценария, объединяющего две части.
Следующим и наиболее очевидным улучшением этой идеи является создание системы для автоматического развертывания приложения после того, как оно скомпилировало и прошло свои модульные тесты. Есть много способов сделать это, от покупки высококлассных приложений у надежных поставщиков, до написания собственной системы Heath Robinson , основанной на клее, ножницах и клейкой ленте; однако, для меня, независимо от того, как вы смотрите на это, всегда будет только два жизнеспособных способа достижения автоматического развертывания. Первый — это метод вытягивания, а секунд — его аналог: push.
Предполагая, что у вас есть Hudson, Jenkins или какой-либо другой сервер сборки, который автоматически компилирует и тестирует модули проверки вашего кода, тогда PULL-процесс — это некоторый сценарий или процесс, который выполняется на вашем компьютере Tomcat, который запускается вручную или автоматически, и
Тянет последний WAR-файл из выходного репозитория вашего сервера сборки, развертывая его на вашем сервере Tomcat.
С другой стороны, процесс PUSH включает сервер сборки, выполняющий сценарий или выполняющий некоторый процесс, который доставляет или PUSHES файл WAR с сервера сборки на ваш веб-сервер.
Примером push-системы может служить плагин Maven Tomcat, выполняющий цель tomcat:redeploy как часть вашего процесса сборки. Например, « mvn install tomcat:redeploy ». Это означает, что когда ваша сборка Hudson или Jenkins выполняется и все ваши тесты пройдены, ваш WAR-файл автоматически развертывается на вашем сервере; однако, это не единственный доступный механизм push, и у него есть недостаток, который присущ всем системам, которые используют ваш сервер Tomcat как часть процесса развертывания.
Проблема использования tomcat как части процесса развертывания связана не с tomcat, а с вашим кодом. Вы должны быть уверены, что ваше приложение не содержит утечек памяти, что иногда бывает трудно сделать. Если у вашего приложения есть утечка памяти, то после java.lang.OutOfMemoryError: PermGen или двух вы получите исключение java.lang.OutOfMemoryError: PermGen tomcat, что означает, что для перезапуска сервера требуется ручное вмешательство. Помните, что исключение java.lang.OutOfMemoryError: PermGen является вашей ошибкой, а не ошибкой кота.
Мне кажется, гораздо лучше управлять перераспределением вашего приложения без помощи tomcat. Это позволяет выполнять основные шаги
- выключение вашего сервера Tomcat
- очистка любых каталогов развертывания
- определение точки отката
- развертывание новой версии вашего приложения
- перезапуск сервера
Преимущество остановки и перезапуска сервера состоит в том, что у вас есть «чистый» сервер, на котором можно начать тестирование, и, учитывая это, приведенный ниже пример сценария демонстрирует все вышеперечисленные моменты, используя пример моего address из репозитория CaptainDebug Github .
|
001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
032
033
034
035
036
037
038
039
040
041
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
057
058
059
060
061
062
063
064
065
066
067
068
069
070
071
072
073
074
075
076
077
078
079
080
081
082
083
084
085
086
087
088
089
090
091
092
093
094
095
096
097
098
099
100
101
|
#!/bin/bashecho 'Running Address Application install Script'TOMCAT_VERSION=apache-tomcat-7.0.33-blog# The FTP server holding the tomcat binariesSERVER=<Your Server Name>REPOSITORY=/.m2/repository/ARTIFACT_ID=com/captaindebug/address/APP=addressTYPE=WARSERVER_USER=<Your User Name>SERVER_PASSWORD=<The Password Goes Here>CUT_DIRS=6NEW_VERSION_ARG=$1wait_for_shutdown() { i=1 while [ $i -le 20 ] do ps -ef | grep catalina.startup.Bootstrap > fred.txt if ls -l fred.txt | grep 81 then i=21 else i=`expr $i + 1` sleep 1 fi done}check_version() { if [ -z $NEW_VERSION_ARG ] then VERSION=1.0.0-BUILD-SNAPSHOT else VERSION=$NEW_VERSION_ARG fi echo 'Using version $VERSION'}make_app_location() { check_version APP_LOCATION=$REPOSITORY$ARTIFACT_ID$VERSION/$APP-$VERSION.$TYPE}do_shutdown() { cd ../$TOMCAT_VERSION bin/shutdown.sh wait_for_shutdown}clean_directories() { echo changing directory cd ../$TOMCAT_VERSION/webapps pwd rm -rf $APP rm $APP.$TYPE}get_new_version() { WAR_FILE=ftp://$SERVER_USER:$SERVER_PASSWORD@$SERVER$APP_LOCATION echo $WAR_FILE wget -r -nH --cut-dirs=$CUT_DIRS $WAR_FILE}create_rollback_point() { DATE=`date` BAK_FILE=$APP-$VERSION.$TYPE.$DATE.bak echo 'Backup file is $BAK_FILE' mv '$APP-$VERSION.$TYPE' '$BAK_FILE' ln -s '$BAK_FILE' $APP.$TYPE}restart_server() { cd .. pwd bin/startup.sh}make_app_locationdo_shutdownclean_directoriesget_new_versioncreate_rollback_pointecho 'The directory now looks like this:'ls -lrestart_server |
В этом сценарии на моем сервере Hudson создается пример кода адреса, и результат сохраняется в репозитории Maven. Сценарий находится в каталоге сценариев, который находится на том же уровне, что и сервер: apache-tomcat-7.0.33-blog . В сценарии используется метод Хита Робинсона, который завершает работу сервера и обеспечивает его отключение перед продолжением. Это делается путем проверки размера файла вызова временного файла fred.txt . При продолжении он очищает существующие каталоги, удаляя каталог развертывания address и символическую ссылку на файл war. Затем он использует wget для захвата новой версии приложения, причем версия указывается либо в командной строке, либо по умолчанию — 1.0.0-BUILD-SNAPSHOT .
Следующее, что нужно сделать, это создать точку отката, чтобы мы могли откатить последнее развертывание, если обнаружим, что оно содержит кучу отвратительных ошибок. Первый шаг здесь — переименовать переданный WAR-файл, добавив дату и расширение «.bak». Следовательно,
address-1.0.0-BUILD-SNAPSHOT.WAR
будет выглядеть так:
address-1.0.0-BUILD-SNAPSHOT.WAR.Tue 1 Jan 2013 20:18:21 GMT.bak
Добавление даты полезно при развертывании снимков, а «.bak» означает, что файл не будет загружен tomcat. Второй шаг в настройке отката достигается с помощью символической ссылки на переименованный файл WAR, так что развернутая WAR всегда будет называться
address.war независимо от любого номера версии, встроенного в имя файла.
Использование символической ссылки таким образом позволяет нам откатить версии приложения, остановив сервер, удалив символическую ссылку, создав новую символическую ссылку на старую версию приложения, а затем перезапустив сервер.
Последняя строка скрипта перезапускает сервер.
Следующее, что нужно запомнить, это сохранить ваш скрипт в системе контроля версий.
Да, я знаю, что этот сценарий не так элегантен, как мог бы быть. Если у кого-то есть предложения по улучшению, пожалуйста, дайте мне знать …
Дополнительным преимуществом использования такого сценария является то, что вы можете использовать один и тот же сценарий для развертывания файла WAR вашего приложения в любой среде: dev, test, UAT, production или в любой другой. Преимущество этого в том, чтобы сделать вашу локальную среду разработки чуть более похожей на производственную среду; идея заключается в том, что это минимизирует ошибки и ошибки развертывания, делая вашу жизнь немного проще. Помните, давно прошли дни, когда вы могли сказать «хорошо, что это работает на моей машине» жалобе парней из ops, что ваше приложение не работает.
Следующее звено в цепочке развертывания состоит в том, что теперь что-то должно вступить во владение и запустить набор автоматических приемочных тестов, но об этом позже …
Справка: супер быстрое развертывание приложений Tomcat с использованием сценария PULL от нашего партнера по JCG Роджера Хьюза в блоге Captain Debug’s Blog .