自动化| 自动化变更的常见问题之环境变量

前言

自从我们系统变更上自动化后，我们的变更管理人员普遍反馈很好。不仅变更效率提升可以提前下班，而且可以节省很多人力，比如一个数据库改密动作，之前人工方式需要DBA、应用管理员以及中间件管理员等多方配合才能完成，在自动化上了之后可以很好的将各方的操作串联起来，只需一个人一键启动即可，正常情况下甚至不需要人懂得业务逻辑，由原来需要3个专业的人现场干的事情现在只需1个值班的人操作即可！

当然做自动化也不是一帆风顺的，需要前期规范的统一和理念的铺垫。技术层面也会碰到很多问题，比如前文（点击可阅读）提到的问题。还有变更自动化最常见的问题就是环境变量问题。

所谓环境变量问题就是用自动化执行命令可能会丢失应用所需的环境变量，导致应用没办法拉起来，或者可以正常拉起应用但是可能会有各种编码问题。为此这里主要记录和分享下我们碰到的这类问题。

Login shell和non-login shell

我们登陆服务器一般是使用远程ssh方式登陆操作相关shell命令，而登陆服务器执行shell分为login-shell和non-login-shell两类，用SSH客户端（比如SecureCRT）登陆Linux系统时，要求输入用户名/密码登录或根据SSH key登录时，就是login shell；而在某台机器A上使用SSH免密码登录B机器，在B机器上执行Shell脚本，就是non-login shell。

Login shell和non-login shell加载的环境变量：

•    login shell加载环境变量的顺序是：① /etc/profile ② ~/.bash_profile ③ ~/.bashrc ④ /etc/bashrc

•    non-login shell加载环境变量的顺序是：① ~/.bashrc ② /etc/bashrc

/etc 下的是系统环境配置，对所有用户有效，但是/etc/profile只对login shell有效，而/etc/bashrc对login shell和non-login shell都有效； ~目录下的是当前用户环境配置，当前用户环境配置会继承/etc系统环境配置。

我们自动化用的是基于ansible实现的，而ansible在目标机器上远程执行Shell脚本时，也是non-login shell，其他自动化一般也是类似的non-login shell方式，这一点一定要记住。

问题描述

1、 远程执行数据库sql命令失败，登陆本机执行成功

2、 远程启动weblogic应用不生效，登陆本机启动weblogic应用生效

解决方法

了解了Login shell和non-login shell的区别解决方法就很明显了，一般有如下几种解决方式：

•    将login-shell和non-login shell都需要的环境变量配置放在~/.bashrc中，其它配置放在~/.bash_profile中；

•    如果环境变量配置只放在~/.bash_profile中，需要执行non-login shell时先source ~/.bash_profile再执行命令；

•    如果自动化底层用的是Ansible，则可以用become以及其他一些相关的选项来提供远程执行过程中进行用户切换的功能（推荐首选），相当于执行su – [remoteuser] –c ‘shell command’；

其他妖怪问题

自动化变更中的环境变量问题基本这几中方式就可以搞定了。但是我们在自动化改造过程中还碰到过tomcat无法远程启动问题，本机手动执行tomcat正常，使用ansible自动化的playbook操作tomcat显示无异常，但是查看进程却没有tomcat服务。后来调用在shell脚本启动tomcat需要加上后台执行命令nohup…&就可以了，感觉是ansible的shell模块执行完就释放掉当前进程了。

总结

我们自动化推广已经有段时间了，感受最深的是技术问题再难也可以解决，无非是多几行命令或者多增加几个人天投入而已，规范的执行和自上而下的理念的形成才是自动化推广成功的关键，自动化最怕的就是那种朝令夕改和突发奇想，这种只会把管理人员带入无穷无尽的深渊！

最不喜欢的就是变更时手忙脚乱你争我夺一整天的场景，来时一杯茶，去时杯中犹有余温的从容淡定是我一直坚持自动化的理念，你能认可吗？