使用PULL脚本进行超快速Tomcat应用程序部署

如果您设法阅读了我的最后一篇博客，您会记得我演示了一个简单的脚本，用于通过从conf文件中拆分tomcat二进制文件，将二进制文件存储在FTP服务器上以及版本为conf的文件在服务器上创建新的tomcat安装。控制，并用脚本将这两个部分重新组合。

此想法的下一个也是最明显的改进是创建一个用于在应用程序编译并通过其单元测试后自动部署的系统。 有很多方法可以做到这一点， 从有希望的供应商那里购买高端应用程序，到使用胶水，剪刀和胶带编写您自己的希思·罗宾逊系统； 但是，对我而言，无论您以哪种方式看待，只有两种可行的方法都能实现自动部署。 第一个是pull方法，第二个是它的对应方法：push。

假设您有一个Hudson，Jenkins或其他构建服务器自动编译并对代码签入进行单元测试，则PULL进程是在您的tomcat机器上运行的一些脚本或进程，这些脚本或进程是手动或自动触发的，
从构建服务器的输出存储库中拉出最新的WAR文件，并将其部署在tomcat服务器上。

在另一方面，推过程涉及构建服务器运行一个脚本或进行一些处理，提供，或推 ，从构建服务器WAR文件到您的Web服务器。

推送系统的一个示例是在构建过程中使用运行“ tomcat:redeploy ”目标的Maven Tomcat插件 。 例如，“ mvn install tomcat:redeploy ”。 这意味着当您的Hudson或Jenkins构建运行并通过所有测试时，您的WAR文件将自动部署到您的服务器。 但是，这不是唯一可用的推送机制，并且确实存在所有在部署过程中使用tomcat服务器的系统中固有的缺点。

在部署过程中使用tomcat的问题不在于tomcat，而在于您的代码。 您必须确保您的应用程序不包含任何内存泄漏，这有时很难做到。 如果您的应用程序确实发生内存泄漏，则在重新部署一两次后，您将收到tomcat抛出的java.lang.OutOfMemoryError: PermGen异常 ，这意味着需要人工干预才能重新启动服务器。 请记住， java.lang.OutOfMemoryError: PermGen异常是您的错，而不是tomcat的错。

对我来说，在没有tomcat的任何帮助的情况下管理应用程序的重新部署似乎要好得多。 这使您可以执行以下基本步骤：

1. 关闭您的tomcat服务器
2. 清理所有部署目录
3. 定义回滚点
4. 部署新版本的应用
5. 重新启动服务器

停止并重新启动服务器的好处是，您有一台“干净”的服务器可以在其上开始测试，因此，请记住以下示例脚本，使用我来自CaptainDebug Github存储库的address示例演示了上述所有要点。

#!/bin/bash

echo 'Running Address Application install Script'

TOMCAT_VERSION=apache-tomcat-7.0.33-blog

# The FTP server holding the tomcat binaries
SERVER=<Your Server Name>
REPOSITORY=/.m2/repository/
ARTIFACT_ID=com/captaindebug/address/
APP=address
TYPE=WAR

SERVER_USER=<Your User Name>
SERVER_PASSWORD=<The Password Goes Here>
CUT_DIRS=6
NEW_VERSION_ARG=$1

wait_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_location
do_shutdown
clean_directories
get_new_version
create_rollback_point

echo 'The directory now looks like this:'
ls -l

restart_server

在这种情况下，我在Hudson服务器上构建了地址示例代码，并将结果存储在Maven存储库中。 该脚本位于与服务器相同级别的脚本目录中： apache-tomcat-7.0.33-blog 。 该脚本有一个非常希思·罗宾逊（Heath Robinson）的方法，可以关闭服务器并确保在继续操作之前将其关闭。 它通过检查临时文件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 。

通过这种方式使用符号链接，可以通过停止服务器，删除符号链接，创建到旧版本应用程序的新符号链接，然后重新启动服务器来回滚应用程序版本。

脚本的最后一行将重新启动服务器。

接下来要记住的是将脚本存储在版本控制中。

是的，我知道此脚本不如应有的优雅。 如果有人有改进的建议，请告诉我...

使用这样的脚本的另一个好处是，您可以在每个环境（开发，测试，UAT，生产或任何环境）中使用相同的脚本来部署应用程序的WAR文件。 这样做的好处是使您的本地开发人员环境离生产环境只有一点点距离。 其想法是，这将最大程度地减少部署错误和错误，使您的生活变得更加轻松。 请记住，当您可以说“运维在我的机器上正常运行”的日子已经过去了，而运维人员则抱怨您的应用程序无法正常工作。

部署链中的下一个链接是，现在应该接管并运行一组自动验收测试，但稍后会进行更多……
参考：来自Captain Debug博客博客的JCG合作伙伴 Roger Hughes 使用PULL脚本进行的超快速Tomcat应用程序部署 。

翻译自: https://www.javacodegeeks.com/2013/01/super-quick-tomcat-app-deployment-using-a-pull-script.html