阿里雲(二)nginx代理綁定域名以及gradle項目cargo遠程部署tomcat9

0.前提：
在上一篇文章的3.5處提到 cargo遠程部署tomcat9 和通過修改server.xml消除端口項目名 兩個操作會衝突，所以使用nginx代理來實現域名直接訪問項目，然後cargo實現遠程部署tomcat9。

1.nginx代理實現域名直接訪問項目
項目中這樣寫的：

正常情況訪問是這樣：域名:端口/項目名/
想要的效果是這樣:

1.1 首先在阿里雲服務器中安裝nginx
（轉）
這邊照着操作到這一步就完成了

然後將nginx服務添加到service
實現以下命令啓動關閉

service nginx start
service nginx stop

1.2 修改nginx.conf
如果安裝時 直接./configure沒有修改默認配置的話，路徑在/usr/local/nginx/conf
修改紅框裏的內容

增加upstream節點，名稱隨便
service_name用域名吧，之後再tomcat配置中要用到（service_name爲虛擬服務器的識別路徑）
location中增加

proxy_pass http://upstream名稱/項目名/

這邊阿里雲安全組要設置80和8088（tomcat改過）端口

1.3 修改tomcat9 server.xml

在host處配置
name爲nginx中的service_name
appBase爲空（有文章寫過，會重啓兩次）
增加context節點

1.4 啓動
重啓tomcat9
啓動nginx （有錯誤會提示，遇到的都是url寫的不規範的情況）
瀏覽器輸入域名成功

2.gradle + cargo遠程部署tomcat9
用的是gradle3.3

2.1tomcat-users.xml
配置manager權限

2.2 build.gradle

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        //gradle腳本需要使用的資源
        classpath("org.springframework.boot:spring-boot-gradle-plugin:1.5.2.RELEASE")
        classpath("com.bmuschko:gradle-cargo-plugin:2.3")
    }
}

repositories {
    mavenCentral()
}

apply plugin: 'java'
apply plugin: 'org.springframework.boot'
apply plugin: 'war'
apply plugin: 'com.bmuschko.cargo'

cargo {
    containerId = 'tomcat9x'
    port = 8088

    deployable  {
        context = 'gmweb'
    }
    remote {
        hostname = 'ip'
        username = 'admin'
        password = 'admin123'
    }
}

sourceCompatibility = 1.8
targetCompatibility = 1.8

dependencies {
    cargo "org.codehaus.cargo:cargo-core-uberjar:1.5.1",
            "org.codehaus.cargo:cargo-ant:1.5.1"
    // web 和 test
    compile("org.springframework.boot:spring-boot-starter-web")
    testCompile("org.springframework.boot:spring-boot-starter-test")
    // 設置內嵌tomcat
    providedRuntime('org.springframework.boot:spring-boot-starter-tomcat')
    // spring boot:run
    runtime('org.springframework.boot:spring-boot-devtools')
    // mysql8需要高版本的
    providedRuntime('mysql:mysql-connector-java:5.1.46')
    // druid
    compile('com.alibaba:druid-spring-boot-starter:1.1.10')
    // mybatis
//    compile('org.mybatis.spring.boot:mybatis-spring-boot-starter:2.0.1')
    // fastjson
    compile('com.alibaba:fastjson:1.2.5')
    // mybatis-plus
    compile('com.baomidou:mybatis-plus-boot-starter:3.1.1')
    // mp3.0.3版本後需要手動添加生成器和模板
    compile('com.baomidou:mybatis-plus-generator:3.1.1')
    compile('org.apache.velocity:velocity-engine-core:2.1')
    // aop
    compile('org.springframework.boot:spring-boot-starter-aop')
    // lombok
    compile('org.projectlombok:lombok')
}

cargo版本要1.5.1，containerId = tomcat9x，這個可以再cargo官網上看到有個對照表
cargo --remote中的用戶密碼就是tomcat-users.xml中設置的

2.3context.xml
位置在
/webapps/manager/META-INF

註釋掉value，以便放開訪問

2.4 啓動
重啓tomcat9
瀏覽器登錄manager（用ip）確認OK

遠程部署，先打war包，再redeploy

2.5 啓動日誌發現mysql驅動註冊失敗

不影響啓動，但是看着不爽
意思是：web 容器重啓一個叫Abandoned connection cleanup thread的線程失敗。是因爲創建了一個內存泄露。
堆棧往上是說：mysql驅動註冊失敗，原因是爲了阻止內存泄露。

目前的解決辦法是：
將mysql包的scope修改爲provided

 providedRuntime('mysql:mysql-connector-java:5.1.46')

然後將mysql包放到tomcat9的lib下

重啓tomcat9

補充網上的解釋：

root cause is that Tomcat have problems to garbage collect the driver because it is registered in a singleton common to several applications. 
Closing one application does not allow Tomcat to release the driver. 

JDBC drivers register themselves in the JVM-wide singleton DriverManager which is shared by all web apps. If you have the same (as in class name) JDBC driver register twice from two different web apps, this might cause your problem. This is even more problematic if your web apps use different versions of the same JDBC driver.

Also, putting JDBC drivers into Tomcat's lib folder will help prevent memory leaks when you redeploy your web app without restarting Tomcat, e.g. if you just put a new WAR file into Tomcat's webapps folder:

The class DriverManager gets loaded by the bootstrap classloader and thereby "lives" globally in the JVM, while Tomcat loads all web apps in their own classloaders. So if a JDBC driver from a web app's WEB-INF/lib folder registers itself in DriverManager, it pins that web app's classloader in memory (and thereby all the classes of that web app), preventing its garbage collection.