Walle的簡介我就不多說了它主要是一個web部署系統工具，具有一鍵快速回滾的功能，它能清晰的記錄 上線單申請、審核、部署和實時操作日誌，能支持各種web代碼發布和回滾,對於jenkins來說應用時比較簡單一點。

對於walle,我現在的公司主要是使用walle實現代碼發布,(搭建可參考 walle搭建)下面是我配置的一個項目,(有修改,理解意思就好)先給大家貼個圖.

各配置的理解如下：

· 代碼的檢測倉庫目錄：如 /data/code/api

· 項目的用戶權限管理 www

· 生產環境的web目錄，該目錄的最後一個目錄不需要創建，發布時自動軟連生成

· Walle的發布臨時目錄，存放web的版本 如： /data/publish/www/api

· 部署前準備任務:pre-deploy （前置檢查）

· 代碼檢出後處理任務post-deploy：如vendor和處理php命令

· 同步後更新軟鏈前置任務pre-release

· 發布完畢後收尾任務post-release：如重啟、一些文件的操作

一、問題出現

今天我在發布代碼的時候出現了錯誤（上線錯誤：更新代碼文件錯誤）

這時，我就重復的再發布，還是不行，這個項目明前兩天還是可以發布的。（這時很納悶），沒辦法，百度找資料，結果沒找到，還是自己解決。

二、解決辦法與思路

1、問題出現地方，post-deploy命令執行不了

這時我就想，是不是post-deploy的命令執行不了，導致上線不了。

解決辦法：

想好就幹，然後，我把項目的post-deploy命令刪除了，然後上線。

測試結果：

結果，上線失敗，還是同樣的錯誤。證明發布不了還是命令的問題。

2、問題出現地方，www沒有權限。

自己思考了一下，既然是post-deploy命令還沒執行，就已經出現了問題，那個可能是。www用戶沒有權限拉取代碼。

解決辦法：

給予代碼檢出目錄的www權限，代碼檢出目錄的擁有者為www，命令如下(操作在walle主機上)

#chown  -R www:www /data/code/api

切換用戶測試

#su – www

代碼拉取，測試post-deploy命令

去到代碼檢出目錄

#cd /data/code/api

#git pull origin master

www用戶測試php命令

#composer update
#php artisan migrate

測試結果：

結果，上線失敗，還是同樣的錯誤。（感覺眼都要黑了）

3、問題出現地方，查看walle日誌。

正常安裝的情況，walle的日誌是放到/tmp/walle/ 目錄下，查看最新的文件。日誌已經自動安照時間來命令的了

解決思路：查看日誌的錯誤地方

#cat /tmp/walle/walle-20180619.log | grep error

發現錯誤如下

果然，我們找到了錯誤了，原來錯誤原因是cp命令復制錯誤，是因為沒有多余的空間導致的，我們找到問題出現的地方就好解決了。

查看本地的磁盤使用情況：

發現果然沾滿了

我們再查看一下Inodes的使用情況，

#df -i

發現它/data目錄Inodes使用情況是很少的。所以是/data的目錄磁盤沾滿了

接下來我們繼續查看data目錄占用是什麽情況導致磁盤空間沾滿的。

# du -sh /data

驚奇的發現，/data目錄占用，還遠遠達到90多G的占用情況，這時，我們已經找到解決的思路了。

解決辦法：

出現了這種情況，我們就已經想到，是/data目錄肯定是被那個進程占用了，解決辦法就是把進程殺死，就基本完事了。Walle部署項目通過php的來執行的，我們把一些占用、/data的線程殺死就可以了

#lsof  | grep /data/code | awk ‘{print $2}’| xargs kill – 9

或者你可以這樣

#lsof | grep  deleted | awk ‘{print $2}’ | xargs kill – 9

（這裏沒能及時截到圖）

殺完後重啟php，因為剛剛的殺死進程的時候，已經把php殺死了

所以需要重啟php

#service php-fpm restart

測試結果：

查看磁盤占用情況，發現占用的空間回來了

重新發布項目，成功了（謝天謝地），艱難的解決了一個問題。

結果分析:

首先是www用戶的權限所引起的，然後就是php進程占用，導致同步不成功。

三、項目問題又出現。

第二天上班，想著發布一下項目上線啦，誰知道，又出現了錯誤，這就讓人崩潰了，明明昨天還能發布的。沒有想得太多，立刻就查看walle的日誌，發現又是磁盤空間不足。

1、問題的再度出現

使用命令查看/data目錄的磁盤使用情況，發現如下

[root@centos api]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   10G   37G  22% /
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G   24K  3.9G   1% /dev/shm
tmpfs           3.9G  612K  3.9G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/vdb1        99G   92G   1.6G  99% /data
tmpfs           783M     0  783M   0% /run/user/0
tmpfs           783M     0  783M   0% /run/user/1004

接著發現我又把php的進程殺掉，再查看一下空間，發現還是那樣。

2、解決辦法。

出現了上面的結果，說明不是進程占用而導致的。說明是有文件占用而導致的。

查看/data的目錄大少

[root@centos api]# du --max-depth=1 -h /data
2.9G    /data/wwwlogs
149M    /data/wwwroot
20G /data/files
68G /data/code
474M    /data/mysql
92G /data

我們發現，源來/data/code目錄出現了問題，使用du --max-depth=1 –h命令，一步步找到文件，刪除文件。

結果：

重新查看/data的使用情況，發現占用的空間已經回來了。重新發布

發布成功，問題解決了。

3、問題出現分析

我在刪除文件的時候，發現，有十幾個文件的重復的，每個文件的大少達幾G，到底是什麽原因導致的呢。

最後發現肯定是自己在發布項目的時候，沒有等到發布完就刷新，然後又安部署，導致重復出現代碼目錄的出現，然後保留在發布目錄，導致累積。

註意事項：

在使用walle上線項目的時候，需要按F12來查看項目是否發布完成，再刷新，這樣的話就不會重復發布，導致代碼文件累積。

四、總結

遇到錯誤，分析日誌是一個很好解決錯誤的辦法。要養成習慣才行。

一次walle項目錯誤處理--巨坑