基於Jenkins+Gitlab的自動化部署實戰

故事背景

　　一箇中小型企業，是典型的互聯網公司，當初期的時候可能運維只能標配到2~3人，此時隨着公司的發展，項目會逐漸增多。前期部署項目可能都是手動的，

俗稱「人肉部署」，這簡直是無比的痛苦，不能忍受的。這樣開發的時間也會耽誤，運維的時間也會耽誤，全都浪費在這些重複性的工做上面，毫無價值可言，

這時候運維終於忍受不了，上了腳本。可是慢慢的發現項目依舊在增加，腳本每次還要更改給開發，效率低下，後來測試環境以及開發環境直接上了jeknins，

每臺開發機器是jeknins agent端，自此，開發環境運維終於解脫了出去。可是線上上線運維依舊、因此得定製一套線上上線的流程標準，而後上jenkins自動化。

前提標準

    想要實現自動化的前提是標準化，例如程序的日誌目錄、程序目錄、程序目錄命名、代碼分支、代碼命名規則、程序高可用. 針對以上內容咱們給開發作了

嚴格的標準並落地執行。

在此我會以Java程序爲例子，由於我見到的最多的就是java程序比較麻煩，而php或者python可能只須要在服務器上git pull更新一下代碼就能夠了。

　　tomcat規則： 每臺服務器放置一個tomcat，tomcat使用ROOT.war，並配置日誌切割

　　程序目錄：統一使用tomcat進行管理，全部的項目統一打出war包，放置tomcat下面命名爲ROOT.war

　　程序日誌：統一放置在規定的目錄，例如: /apps/logs/$app.log

　　代碼分支：不一樣的環境使用不一樣的分支，開發 dev分支， 測試 test 分支， 預發佈 pre分支， 生產線上 master分支。分支隔離，不一樣環境取不一樣環境的配置

　　代碼打包： 由於是java的代碼，咱們選擇的是使用maven進行打包，開發只須要關心代碼層便可

　　高可用： 每一個程序必須支持多節點部署，不可出現單點故障的狀況，不然不予上線.

自動化部署系統

　　由於中型公司不可能配置運維開發，而開發只管開發的，因此運維只能是經過使用開源工具的方式來搭建自動化部署系統，組件以下圖：

 

上圖的Jenkins服務器即本身是本身的agent，gitlab服務器是代碼倉庫服務器，Jenkins服務器會調用腳本，腳本作一些響應的動做進行自動化上線。

自動化上線流程： 

 

下面進行步驟的分解：

 1. 運維人員登陸jeknins，在jenkins界面點擊響應的job，每一個job是更新一個主機，job以服務名+ip組成，點擊後jeknins會調用Shell發佈腳本，下面這些都是腳本完成

 2. 發佈腳本所作的第一步就是獲取此項目的最新的代碼版本

 3. 發佈腳本所作的第二部是使用maven進行打包，每一個maven打包的參數都統一

 4. 將打包好的war包拷貝到目標服務器上面

 5. 將須要上線的主機在前端負載haproxy上面進行下線（針對核心業務，建議這麼作，比較優雅，不太暴力）

      方法參考： http://www.cnblogs.com/topicjie/p/7106860.html

 6.重啓目標主機的tomcat服務

 7.測試url訪問，返回是否正常

 8.在haproxy上線該主機

 

腳本實例

 下面是一個線上使用的上線腳本，scp是經過ssh免密的方式，而且部署tomcat是java用戶. tomcat路徑是/usr/loca/tomcat，每臺主機一個tomcat

腳本必須指定要更新的主機，上線代碼路徑

分支線上默認master ,mvn配置爲product參數

 注意： 此腳本中不包含 5，7，8 步驟，若是須要，請自行補充。

#!/bin/bash
################################################################## 
#
# Date :  2016/07/15
# Email:  gengjie@outlook.com
# Proj :  xx java項目
#
# 主要功能是更新線上tomcat服務使用.
# 使用此腳本必須配置java用戶免密碼登陸 
# 第一次必須手動將代碼clone到BASE_CODE_PATH目錄
################################################################## 
. /etc/profile

# 定義此項目所包含的主機,以空格隔開，必須嚴格遵照
inc_host=("192.168.24.50" "192.168.24.51")

##### *** 定義項目代碼存放目錄,必須定義正確 ***  ####
CODE_PATH="/app/code/xxxxxx"

# 定義tomcat實例目錄
Tomcat_PATH="/usr/local/tomcat"

# 定義git分支,默認是master分支
CODE_BRANCH='master'

# 定義編譯配置文件,生產環境默認應是product,此處是pom.xml文件中定義
MVN_CONF="product"

# 獲取須要更新的主機IP
U_host="$1"

# Define help
usage() {
    echo
    echo -e "   Usage : sh ./`basename $0` ipaddress"
    echo
}

code_pull() {

    echo "[Info] --->>> 項目開始更新代碼... <<<---"

    cd $CODE_PATH
    git checkout $CODE_BRANCH
    git pull -u origin master:master 

    if [ $? -ne 0 ];then
        echo "Git Pull Code Error"
        exit 1
    fi

    echo "[Succ] --->>> 項目代碼更新完成... <<<---"
    echo 
}


# Define build war
mvn_build() {
    cd $CODE_PATH
    echo "[Info] --->>> 項目開始編譯... <<<---"
    mvn clean package -P $MVN_CONF

    if [ $? -ne 0 ];then
        echo "[Error] Compile Error,Please Check Your Code."
        exit 1
    fi
    echo "[Succ] --->>> 項目編譯完成... <<<---"
    echo
}

# Define publish 
push_remote() {

    echo "[Info] --->>> 開始發佈主機: $U_host  <<<---"

    ssh $U_host "/bin/rm -rf ${Tomcat_PATH}/webapps/ROOT*"
    scp ${CODE_PATH}/target/*.war $U_host:$Tomcat_PATH/webapps/ROOT.war
    ssh $U_host "/bin/sh /app/scripts/stop_tomcat.sh"
    sleep 3
    ssh $U_host "source /etc/profile;/bin/sh ${Tomcat_PATH}/bin/catalina.sh start"  

    echo "[Succ] --->>> 主機: $U_host 發佈完成. <<<---"
    echo

}

# check host
check_host() {

    for host in  ${inc_host[@]};
    do
        if [[ "$U_host" == "$host" ]];then
            return 0
        fi
    done
    return 1
}

# Check user
check_user() {
    if [ `whoami` != 'java' ]; then
        echo "---------------------------------------------------"
        echo "You must use the Java user to run this script !!!"
        echo "---------------------------------------------------"
        exit 3
    fi
}

check_user

#check args
if [ $# -ne 1 ];then
    usage;exit 1
fi
if [ $1 == "-h" -o $1 == "--help" ];then
    usage;exit 1
fi

check_host
if [ $? != 0 ];then
    echo "Please check the server ip address to be updated !"
    exit 64
fi

code_pull
mvn_build
push_remote    

　　

 自此，以上能夠實如今jenkins點擊一下，服務一會本身就上好了，雖說還有不少地方須要改進，可是通常中小型公司採用這種方式則是足夠了，

只能持續的進行優化，固然，再厲害一點的公司能夠本身開發運維平臺。