运维如何写出不耍流氓的Shell脚本

uploads/article/20161202/08d232eea128bb46cf9e47ff1ebd20df.jpg

声明

大家都是文明人,尤其是做运维的,那叫一个斯文啊。怎么能耍流氓呢?赶紧看看,编写 SHELL 脚本如何能够不耍流氓。

MySQL备份脚本案例

1、不记录日志的shell 脚本就是耍流氓!
我们经常在工作中会遇到一个苦恼的事情,一个 Shell 脚本到底干了什么,什么时候开始执行,什么时候结束的。尤其是数据库备份,我们想知道我们的 MySQL 数据库备份时间。所以给脚本加日志显得尤为重要。那么我们的脚本应该有一个日志的函数,专门用于记录日志:

#!/bin/bash

# Shell Env
SHELL_NAME="shell_template.sh"
SHELL_DIR="/opt/shell"
SHELL_LOG="${SHELL_DIR}/${SHELL_NAME}.log"
LOCK_FILE="/tmp/${SHELL_NAME}.lock"

#Write Log 
shell_log(){
    LOG_INFO=$1
    echo "$(date "+%Y-%m-%d") $(date "+%H-%M-%S") : ${SHELL_NAME} : ${LOG_INFO}" >> ${SHELL_LOG}
}

shell_log "shell beginning, Write log test"
shell_log "shell success, Write log test"

上面的脚本我编写了一个日志函数shell_log,每次记录日志,我们直接执行shell_log把日志内容当作第一个参数传给它就可以了,赶紧试试。

[root@labs shell]# cat shell_template.sh.log
2016-08-27 06-01-19 : shell_template.sh :shell beginning ,write log test
2016-08-27 06-01-19 : shell_template.sh :shell success ,write log test

2、直接就能执行的Shell脚本很容易耍流氓
一个脚本直接就能执行?难道不是直接就能执行吗?试想,你临时编写了一个特别重要的脚本,干的事情可能有破坏性,一不小心被别人./执行了怎么办呢?而且很多时候我们一个脚本的功能可能有多个,所以我们有必要让用户可以选择进行执行。

#!/bin/bash

# Shell Env
SHELL_NAME="shell_template.sh"
SHELL_DIR="/opt/shell"
SHELL_LOG="${SHELL_DIR}/${SHELL_NAME}.log"
LOCK_FILE="/tmp/${SHELL_NAME}.lock"

#Write Log 
shell_log(){
    LOG_INFO=$1
    echo "$(date "+%Y-%m-%d") $(date "+%H-%M-%S") : ${SHELL_NAME} : ${LOG_INFO}" >> ${SHELL_LOG}
}

# Shell Usage
shell_usage(){
    echo $"Usage: $0 {backup}"
}


# Backup MySQL All Database with mysqldump or innobackupex
mysql_backup(){
    shell_log "mysql backup start"
    shell_log "mysql backup stop"
}

# Main Function
main(){
    case $1 in
        backup)
            mysql_backup
            ;;
        *)
            shell_usage;
    esac
}

#Exec
main $1

上面的脚本我们编写了shell_usage函数,用来告诉用户,这个脚本的使用方法。同时,我要强调一下,像编写Shell, 我们经常是面向过程的,建议以函数为单位,这样脚本非常的清晰可读。赶紧执行以下看看效果吧。

[root@labs shell]# ./shell_template.sh
Usage: ./shell_template.sh {backup}

3、不加锁的Shell脚本就是让别人耍流氓
你编写的脚本能多个人同时执行吗?如果不能,那么如果多个人一起执行会怎么样呢?想想是不是有点冒冷汗。所以,不要给我们的其它小伙伴留下陷阱。不过如果你公司就你一个运维,真的不用怕吗?试想如果是定时任务再运行这个脚本,上一次没有运行完毕,然后到时间又运行了?然后,然后,然后,后果好可怕。

#!/bin/bash

# Shell Env
SHELL_NAME="shell_template.sh"
SHELL_DIR="/opt/shell"
SHELL_LOG="${SHELL_DIR}/${SHELL_NAME}.log"
LOCK_FILE="/tmp/${SHELL_NAME}.lock"

#Write Log 
shell_log(){
    LOG_INFO=$1
    echo "$(date "+%Y-%m-%d") $(date "+%H-%M-%S") : ${SHELL_NAME} : ${LOG_INFO}" >> ${SHELL_LOG}
}

# Shell Usage
shell_usage(){
    echo $"Usage: $0 {backup}"
}

shell_lock(){
    touch ${LOCK_FILE}
}

shell_unlock(){
    rm -f ${LOCK_FILE}
}

# Backup MySQL All Database with mysqldump or innobackupex
mysql_backup(){
    if [ -f "$LOCK_FILE" ];then
        shell_log "${SHELL_NAME} is running"
        echo "${SHELL_NAME}" is running && exit
    fi
    shell_log "mysql backup start"
    shell_lock
    sleep 10
    shell_log "mysql backup stop"
    shell_unlock
}

# Main Function
main(){
    case $1 in
        backup)
            mysql_backup
            ;;
        *)
            shell_usage;
    esac
}

#Exec
main $1

我为脚本增加了两个函数shell_lock和shell_unlock非常简单,就是创建一个锁文件。然后再执行的时候先判断锁文件是否存在,如果存在说明有其它用户在执行,就退出。如果没有自己创建锁文件,开始执行,执行完毕删除锁文件。

好的,现在你可以赶紧再开一个窗口试试能不能执行这个脚本,或者到/tmp目录下看看是否创建了锁文件。请注意:如果已知的异常退出,一定也要删除这个锁文件。

一般创建锁文件放到/var/lock/subsys/目录下,比如postfix的锁文件就是:

prog="postfix"
lockfile=/var/lock/subsys/$prog

做好事须留名
对于一个功能脚本来说,貌似还少了点什么。对,就是注释!我们要说明白这个脚本是干啥的。或者以后你离职后,别人看到这个脚本之后,我擦,这么牛掰的脚本是谁写的呢?不要怕,写上你的大名。

#######################################################
# $Name:         shell_template.sh
# $Version:      v1.0
# $Function:     Backup MySQL Databases Template Script
# $Author:       Jason Zhao
# $organization: https://www.baidu.com 
# $Create Date:  2016-08-27
# $Description:  You know what i mean,hehe
#######################################################

当然还有很多编写脚本的技巧,没法一一描述,不过如果能掌握上面的三种技巧,立马感觉编写的脚本有点高大上,有木有?

3 个评论

一般创建锁文件放到/var/lock/subsys/ 目录下,比如postfix的锁文件就是: prog="postfix" lockfile=/var/lock/subsys/$prog
这个细节还不错。
shell编码规范可以参考: https://www.jb51.net/article/198593.htm#_label3_0_4_0 https://zh-google-styleguide.readthedocs.io/en/latest/google-shell-styleguide/naming_conventions/#section-3 https://www.cnblogs.com/chinas/p/7073061.html#_lab2_0_2

要回复文章请先登录注册