我在写shell自动部署脚本碰到的问题
如题，最早接触shell脚本是大学的时候，感觉好复杂，最近几年工作中也零零散散的接触过很多，很多都是网上找资源进行解决，这两天在写自动部署的初始化脚本，感觉还是挺多不足的。
shell脚本写的有点c语言的感觉，是过程语言，但是如何模块化就非常重要了，首先我的第一个版本是完成了从远端服务器获取资源文件，一键部署tomcat，jdk，生成backup目录，log目录，web目录，script目录，tools目录，生成tomcat自启动脚本。以及和远端服务器的交互等。整个shell脚本写下来花了半天的时间，一个方法搞定全部，没有错误处理机制，没有合适的操作日志。所有就有了下面的重构。
shell脚本中遇到的问题
1.执行脚本的日志打印，错误记录，类似于日志机制没有
v1.0的版本采用的日志方式是，直接print，遇到错误直接return
v2.0的方式，现在的方式是模块化日志方式，看代码
#调试,调用wget记录日志 debug() { if [ $global_is_debug = "true" ];then debug_str=$1 echo "debug:##### ${debug_str} #####\n" fi } #错误,调用wget记录日志 error() { echo "error:########### $1 ############\n" }
2.用wget方式和远程服务器交互，特殊字符处理
v1.0：直接wget –i 一个列表，然后存到本地，一系列操做后，删除文件
优点是，简单粗暴，缺点是不能适应自动化部署
v2.0：封装wget模块，通过和远程服务器交换，动态获取下载列表，根据需要保存到指定目录，优点：更具有扩展性，缺点是，服务器请求多
在和远端服务器交换的时候设计到特殊字符及汉子的处理，v2.0封装了一个urlencode方法，进行转码。代码如下：
#进行编码,编码结果放在全局变量里面 urlEncode() { #需要被编码的字符串 encode_str_params1=$1 debug "${encode_str_params1}" #编码 global_encode_str=`echo "${encode_str_params1}" | tr -d '\n' | xxd -plain | sed 's/\(..\)/%\1/g'` return }
补充一点：wget 对于请求的url带有特殊字符的处理，我后台采用的是struts2，提供的api接口带有 例如 http//t.cn/api/linux!errorDebug?xx=oo&oo=xx
你采用传统的方式都会报bad参数的错误，调试很久都未果，我的经验是，采用post方式，如果有特殊字符的 需要用 ‘’ 包含起来，比如上述的。
下面的代码中wgetPost是封装了一个将请求文件存到指定目录的功能，文件名命名方式为 debug_时间_全局的自增字段。
第一行请求变量参数里有特殊字符，后面跟着的字符串也需要用‘’包含起来，具体为什么，应该是shell的解释器就是这样规定的，‘’小括号里不能包含变量
wgetPost ${global_log_url}'logDebug?' ${global_project_log_debug_path}/ "debug_"$(date +%Y-%m-%d-%H-%M-%S)"_${global_debug_file_log_num}" ${inner_post_data}
#wget简单封装
#inner_url: 访问地址
#inner_dir: 目录
#inner_file: 文件名称
#inner_post_data 请求的数据
wgetPost()
{
inner_url=$1
inner_dir=$2
inner_file=$3
inner_post_data=$4
#容错处理
mkdir -p -m 777 ${inner_dir}
wget --post-data="${inner_post_data}" ${inner_url} -O ${inner_dir}${inner_file}".bk" -o /dev/null
inner_bytes=$(du -s ${inner_dir}${inner_file}.bk | awk '{print $1}')
if [ $inner_bytes -ne 0 ];then
cp -rf ${inner_dir}${inner_file}.bk ${inner_dir}${inner_file}
else
echo "wget ${inner_url} failed"
fi
}
3.sed命令在处理特殊字符替换的时候处理
sed –i ‘s/a/b/g’ 一般是这种方式，但是如果遇到要替换的字符或者被替换的字符有*_/ \的时候，就不适用了，解决的方式是利用#号
可以通用点,就是将源字符串，替换为目标字符串
source_str="abc" target_str="xxoo" sed -i "s#${source_str}#${target_str}#g" str.txt
4.合理的代码编程规范
编码规范很重要，v1.0版本写的比较随意，变量名比较混乱，维护花时间，
v2.0注意这个问题，目前的规范是：
1.所有的静态变量 前缀为 static_xx_xx
2.所有的全局变量 前缀为 global_xx_oxx
3.参数为 in_xx_xx
4.方法内的局部变量为 inner_xxdf
5.方法的命名规则遵循通俗易懂
6.模块化操作，讲究代码
5.目录的权限问题
目录的权限问题是个非常头疼的问题，因为所有的操作为root操作，如果控制到非常精细力度的权限，这块都要头疼死，在v2.0稳定的基础上，保证自动部署系统的如期完成，顶级目录不开放修改，子目录为777权限，任何人可以修改，等自动部署系统前台完成后，就可以完全回收权限了
6.日志记录的级别
日志这个东西很重要，v1.0的版本是采用打印到控制台的方式
v2.0采用方式是进行级别控制 ，分为debug 和error 方式，debug模式有开关配置，error模式之间输出，并且通过wget方式入库，及时反馈到前台
7.应用服务器及依赖环境的准备方式
依赖环境也很重要，自动部署讲究一个自动部署，统一规范，但是线上的版本很多，比如jdk有1.5,1.6,1,7 同时 tomcat也会有各种版本，memcache等都各不相同。为了统一，首先取线上稳定的tomcat版本清理后作为基础版本，例如tomcat.7.39.tar.gz，解压后利用脚本动态更改配置后就可以使用，还有jdk的安装目录等，现在的做法就是 把线上的版本都收集起来，通过后台网页工具进行选择，自定义配置，首先应用环境的基础版本是清洁版本，配置文件已经进行过优化，只需要替换几个常量即可，这里完成的是，1.tomcat的端口号，关闭端口，启动时的jdk目录，自启动脚本的tomcat-home等
