В Tomcat есть два варианта развертывания войны:
- скопировать войну в папку веб-приложений
- загрузить войну на / manager / text / deploy конечная точка http, опубликованная вашим tomcat
Вот несколько подходов к развертыванию войны и получению статуса развертывания (успех | неудача)
Вы можете поместить один из следующих фрагментов на этапе развертывания вашего конвейера или перейти на Groovy.
/ менеджер / текст / развернуть
Это конечная точка, которая позволяет загружать войну с удаленного хоста на сервер Tomcat и в качестве ответа:
- Http статус 200 для успеха или неудачи без различия
- Http Body вроде:
OK - Deployed application at context path /foo
FAIL - Deployed application
at context path /my_app
but context failed to start
Итак, чтобы обнаружить, что все в порядке, я выполняю эту проверку:
CURL_RESPONSE=$(curl -v -u $TOMCAT_USER:$TOMCAT_PASSWORD -T $WAR_PATH "http://$TOMCAT_HOST:$TOMCAT_PORT/manager/text/deploy?path=/$CONTEX_NAME&update=true")
if [[ $CURL_RESPONSE == *"FAIL"* ]]; then
echo "war deployment failed"
exit 1
else
echo "war deployed successfully "
exit 0
fi
Здесь вы можете найти необходимые конфигурации для включения этой конечной точки:
Копирование файла войны в веб-приложения
После копирования файла war в веб-приложения вы можете перечислить развернутые приложения и найти имя вашего приложения в ответе http body:
OK - Listed applications for virtual host localhost
/manager:running:0:manager
/:running:0:ROOT
/docs:running:0:docs
/examples:running:0:examples
/host-manager:running:0:host-manager
/my_app:running:0:my_app
/my_other_app:running:0:my_other_app
Вы можете использовать цикл с разрывом как максимальное количество попыток.
Здесь вы можете найти необходимые конфигурации для включения этой конечной точки:
/ здоровье или / статус
Это более чисто, и, как я знаю, несколько платформ мониторинга используют эту стратегию.
Все заключается в предоставлении дополнительной конечной точки http в вашем приложении (веб-приложение, api rest, daemon и т. Д.)
Эта конечная точка должна возвращать один из следующих ответов:
http stasus
- (200): означает, что в вашем приложении все в порядке
- (! 200): указывает на наличие проблем в вашем приложении. Если ваше приложение было развернуто неправильно, эта конечная точка вернет 404.
xml или json
{
"status":"200",
"database_connectivity":"200",
"read_write_disk":"200",
"etc":"etc"
}
Наконец, вы можете использовать цикл, чтобы использовать конечную точку / health из вашего конвейера Jenkins. Эта стратегия позволит вам отслеживать ваши приложения с внешних платформ, таких как: