Use shell scripts to complete automated deployment of jar packages

1 Introduction

First of all, we have a springboard, and then a server. What we need to do now is to copy the jar file on the springboard, and then use the script on the server to backup the old jar package and start the new jar package.
It's very simple to use: begin.sh demo-V2.0.jar
implement deployment operations:拷贝jar包到服务器 -> 备份旧服务jar包 -> 启动新服务jar包

2. Springboard machine

The following code is the program on the springboardbegin.sh

#!/bin/sh
fileName=$1
if [ -z "$fileName" ]; then
echo "文件名不能为空"
exit 0
fi
echo "开始拷贝jar文件【$fileName】到hadoop-slave1"
scp $fileName  root@hadoop-slave1:/usr/local/test/
echo "文件传输结束"
ssh root@hadoop-slave1  /usr/local/test/backup-and-start.sh $fileName

To explain, the above program is divided into three parts:

1. Determine if the input jar package name is empty, and it ends if it is empty
2. Jar package will be copied to our hadoop-slave1服务器on
3. Execute the startup script on the hadoop-slave1 serverbackup-and-start.sh

3. Server

Through the code on the springboard above, we know that the springboard will eventually call /usr/local/test/backup-and-start.shthe shell script command on the server . The code of this command is as follows;

#!/usr/bin/env bash
echo "服务器开始部署服务"
projectname="demo"
#打开文件所属的目录，不然远程执行会找不到当前目录
cd /usr/local/test
#新的jar包会当成参数传过来
newJar=$1
echo "新的jar为：$newJar" 
#如果新的jar包为空则退出
if [ -z "$newJar" ]; then
 echo "新的jar不能为空"
 exit 0
fi
#获取旧的jar包名称，当然可能是空的，也可能跟当前名称一致
oldJar=$(ps -ef | grep ${
    
    projectname}|grep -v 'backup-and-start.sh'|grep -v grep|awk '{print $10}'|cut -d '/' -f 2)
echo "当前运行的旧的jar包为：$oldJar" 
#如果新的jar包为空则退出
if [ -z "$oldJar" ]; then
 echo "没有启动的demo服务"
else
 #如果旧的进程还在就将旧的进程杀掉
 oldId=`ps -ef|grep ${
    
    projectname}|grep -v "$0"|grep -v "grep"|awk '{print $2}'`
 echo "$oldId"
 echo "kill old process start ..."
 for id in $oldId
 do
 kill -9 $id
 echo "killed $id"
 done
 echo "kill old process end"
 #获取当前时间
 suffix=".bak-"`date '+%Y%m%d'`;
 echo $suffix;
 #将旧的jar包进行备份
 mv $oldJar ${
    
    oldJar}${
    
    suffix}
fi
#上面的步骤是杀掉旧的进程，下面开始启动新的进程
nohup java -jar ${
    
    1} > ${
    
    1}.log 2>&1 &
echo "服务启动查看进程:"
echo `ps -ef | grep ${
    
    projectname}|grep -v 'backup-and-start.sh'|grep -v grep`

Let me explain that the above has actually done the following tasks:

1. Open the current directory, if remote execution, this step must have
2. Get the name of the jar package of the currently running service
3. If the jar package name is not obtained in step 2, it means that the service is not running and skip to step 6
4. If the jar package name is obtained in step 2, get the id of the process
5. Kill the running process and back up the old jar service
6. Start the new service jar package, the new service jar is the one passed from the springboard
7. Check whether the service has been started

4. Matters needing attention

If it is a script on the server /usr/local/test/backup-and-start.sh, use the following explanation header

#!/usr/bin/env bash

To replace the original explanation header

#!/usr/bin/bash

In order to avoid errors in environmental variables.

The specific reasons are as follows

#!/usr/bin/env bash #lends you some flexibility on different systems
#!/usr/bin/bash     #gives you explicit control on a given system of what executable is called

Advantages of running the program through /usr/bin/env
:

1. Users do not need to find the location of the program in the system (because the location of the command or program may be different in different systems), as long as the program is in your $PATH;

2. It will find and run the default version according to your environment, providing flexibility.

Disadvantages:

1. The downside is that in a multi-user system, someone else places a bash in your $PATH, and an error may occur.

In most cases, /usr/bin/env is the preferred choice because it provides flexibility, especially if you want to run this script in a different version; and the way to specify the specific location#! /usr/bin/bash , In some cases it is safer because it limits the possibility of code injection.