庖丁解Puppet之中級進階篇

庖丁解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. exec 
  6. { "exec-java-web-update": 
  7. cwd => "/root/scripts", 
  8. command => "sh java-web-update.sh", 
  9. user => "root" 
  10. path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin", 
  11.  
  12.  
  13. node 'kaifa' { 
  14. file 
  15. { "/opt/puppet.war": 
  16. source => "puppet://$puppetserver/lgh/puppet.war", 
  17. exec 
  18. { "exec-puppet-web-update": 
  19. cwd => "/root/scripts", 
  20. command => "sh java_web_update.sh", 
  21. user => "root" 
  22. path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin", 


登錄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. exec 
  7. { "exec-java-web-update": 
  8. cwd => "/root/scripts", 
  9. command => "sh /root/scripts/update_java_web.sh", 
  10. user => "root", 
  11. path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin", 
  12.  
  13.  
  14. node 'kaifa' { 
  15. file 
  16. { "/opt/puppet-web-update-file/puppet.war": 
  17. source => "puppet://$puppetserver/lgh/puppet.war", 
  18. notify => Exec["exec-puppet-web-update"], 
  19. exec 
  20. { "exec-puppet-web-update": 
  21. cwd => "/root/scripts", 
  22. command => "sh /root/scripts/update_puppet_web.sh", 
  23. user => "root", 
  24. path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin", 
  25.  


具體成功的日誌,這裏不貼出來了,貼兩個應用程序的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之初級入門篇
 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章