庖丁解Puppet之
中级进阶篇

 

前言：
     公司的web网站是java开发的，所以经常要更新war包，虽然服务器只有几十台，但每次传输文件，然后再在应用服务器上执行更新脚本，是件很麻烦的事，这也是我开始研究puppet的动力，不过通过今天的实验，我发现puppet并不很适合我公司用，但箾已发出了，不想停止，也没办法停止，怎么都要把puppet弄个九成熟，所以就有了本篇的中级进阶博文。

实例二：
通过puppet服务器端向两台客户端传输war包（包括更新），并执行tomcat重启命令，从而达到更新网站程序的要求。
这个实例验证puppet两个功能，一是文件传输，二是执行客户端的shell脚本。
网络拓朴：

环境搭建：
    找公司开发部做三个简单的包，一个java.war包，一个puppet.war包。Java.war包输出为“hello,java”。Puppet.war包输出为“hello,puppet”。还有一个更新包puppet.war，输出内容为“hell,puppet,第二次传输，更新”。这里要注意，后面更新包puppet.war与第一次的puppet.war同名，但内容不一样，为的是模拟同名文件更新问题（网站更新包，也就是项目名是不变的）。

操作：
    在42与31两台服务器上装上jdk和tomcat，具体安装这里暂不说明了，后期补上，修改tomcat程序目录下的index.jsp页面。把原来显示为“If you're seeing this page….”这句话分别改为puppet-web is ok和java-web is ok。这样修改是为了好区分。
 

登录puppet服务器，把java.war与第一次的puppet.war包上传至opt目录

修改puppet服务器的site.pp
 

 
  
  1. node 'nfstest' { 
  2. file 
  3. { "/opt/java.war": 
  4. source => "puppet://$puppetserver/lgh/java.war", 
  5. } 
  6. exec 
  7. { "exec-java-web-update": 
  8. cwd => "/root/scripts", 
  9. command => "sh java-web-update.sh", 
  10. user => "root" 
  11. path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin", 
  12. } 
  13.  
  14. } 
  15.  
  16. node 'kaifa' { 
  17. file 
  18. { "/opt/puppet.war": 
  19. source => "puppet://$puppetserver/lgh/puppet.war", 
  20. } 
  21. exec 
  22. { "exec-puppet-web-update": 
  23. cwd => "/root/scripts", 
  24. command => "sh java_web_update.sh", 
  25. user => "root" 
  26. path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin", 
  27. } 
  28. } 
 
  

 登录nfstest客户端（192.168.133.42）在/root/scripts目录新建一shell，命名为java_web_update.sh.
 --内容如下：
 
  
 
  
  1. #!/bin/bash 
  2. Tomcat_root=/opt/java-web 
  3. Tomcat_file=/opt/java-web/webapps 
  4. Tomcat_cache=/opt/java-web/work 
  5. Java_updatefile_dir=/opt/java-web-update-file 
  6. File_name=java.war 
  7. Cur_Time=`date +%Y_%m_%H_%M` 
  8. Tomcat_process=`ps -ef | grep java-web | grep -v grep | awk '{print $2}'` 
  9. kill -9 $Tomcat_process >/dev/null 
  10. sleep 3 
  11. cd $Tomcat_file 
  12. #tar -zcf /opt/webapps.tar.gz.$Cur_Time * 
  13. rm -rf * 
  14. cd $Tomcat_cache 
  15. rm -rf * 
  16. cd /opt 
  17. cp -f $Java_updatefile_dir/$File_name $Tomcat_file/ 
  18. /opt/java-web/bin/startup.sh >>/root/lgh.log 
 
  
    如果在当前tty下执行脚本没有出现问题，但通过远程调用该脚本时报如下错，是因为在安装jdk时，虽然source /etc/profile了环境变量，但某些场景还是会不生效，所以，安装完jdk后，建议把服务器重启一下，解决这个问题，折腾了我一上午时间。
 Neither the JAVA_HOME nor the JRE_HOME environment variable is defined
 At least one of these environment variable is needed to run this program
 
  
登录puppet服务器执行命令
 Puppetrun nfstest kaifa
 返回日志
Triggering nfstest
 Getting status
 status is success
 nfstest finished with exit code 0
 Triggering kaifa
 Getting status
 status is success
 kaifa finished with exit code 0
 Finished
 登录nfstest客户端查看日志
 Tail –f /var/log/message
 
  
登录kaifa客户端查看日志
 
  
    报错，从日志上看是先执行shell脚本，再执行文件传输，到tomcat程序目录下查看下，发现puppet.war包没有，这种现象与先执行shell，再执行文件传输的理论是一致的。从这可以看出，puppet客户端在执行多项任务时，是不分先后的，即使你在site.pp上写脚本时有先后。所以如果第二步的任务要在第一步完成后才能执行的话，只能使用触发，我们把site.pp改下。
 登录 puppet服务器，修改site.pp
 --内容如下： 
  
 
  
 
  
  1. node 'nfstest' { 
  2. file 
  3. { "/opt/java-web-update-file/java.war": 
  4. source => "puppet://$puppetserver/lgh/java.war", 
  5. notify => Exec["exec-java-web-update"], 
  6. } 
  7. exec 
  8. { "exec-java-web-update": 
  9. cwd => "/root/scripts", 
  10. command => "sh /root/scripts/update_java_web.sh", 
  11. user => "root", 
  12. path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin", 
  13. } 
  14.  
  15. } 
  16.  
  17. node 'kaifa' { 
  18. file 
  19. { "/opt/puppet-web-update-file/puppet.war": 
  20. source => "puppet://$puppetserver/lgh/puppet.war", 
  21. notify => Exec["exec-puppet-web-update"], 
  22. } 
  23. exec 
  24. { "exec-puppet-web-update": 
  25. cwd => "/root/scripts", 
  26. command => "sh /root/scripts/update_puppet_web.sh", 
  27. user => "root", 
  28. path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin", 
  29. } 
  30.  
  31. } 
 
  

 具体成功的日志，这里不贴出来了，贴两个应用程序的web输出。

 
  
 
  

 这两个输入也刚开始搭建tomcat时，输出不一样，说明更新网站成功。
 
  
    刚才我们做的操作是先传文件，然后再执行脚本，这脚本里会调用第一步的文件，所以要注意文件执行的先后顺序。我们再来做个puppet更新。

 登录puppet服务器的opt目录，看下文件包
 
  
    把puppet.war改名为puppet.war.first，把puppet2.war包改名为puppet.war，这样做的目的是不想改site.pp文件内容了，这里要注意目前的puppet.war包内容，应该是”hell,puppet.第二次传输，更新”。
 改名后，执行一下
 Puppetrun kaifa
     同时登录客户端看下日志，发现同名文件正在传输，并且很清楚的说明了文件从哪个MD5变为了哪个MD5值，更新完后，我们访问web就知道，此次更新是否正常。
 
  

 等日志输出为finished catalog run in xxxx seconds，我们打开浏览器访问一下。
 
  
    发现web内容由“hello,puppet”变为“hell,puppet.第二次传输，更新”，达到目的，完满完成任务。
     通过今天的实验，我很有信心在公司的生产环境部署puppet了，我公司主要是更新包传输与本地执行shell脚本，目前的实验来看，已经达到了，我想要的效果。后期就是高级篇了，高级篇是研究puppet的结构，把它弄明白，并编写出模块化的pp资源。
 ：）：该死的开发，“hello”，被他写成“hell”了。
 
  
 
 
  
相关博文阅读：
庖丁解Puppet之初级入门篇