每一次故障排查都是一筆財富，各種狗血經過不表，解決問題之後的那種滿足是不可替代的。

背景

發布系統架構圖簡化如下：

發布架構圖

管理員通過Jenkins調用「發布程序(代號varian，以下簡稱varian)」，發布程序會進行一系列的初始化操作，完成後生成Docker鏡像上傳到Docker倉庫，容器集群更新鏡像，用戶通過負載均衡訪問我們的容器集群。

老的varian採用shell+python開發，配合Jenkins(jdk1.7)進行發布，因內部項目較多，寫了很多兼容腳本，代碼比較亂。

我們計劃對varian進行重構，完全採用python開發，各個功能模塊化，不同類型的項目用樂高的思想拼裝模塊部署發布，降低耦合。

並將jenkins升級到最新版本，jdk同樣升級到1.8。新的varian已經開發完成，現在開始部署測試了，故事就由此開始。

為了降低對現有項目的影響決定重新部署一套新的環境，完全測試通過後將老環境廢棄，直接啟用新環境，新環境信息如下：

系統：Debian8
語言：Python3.4
JDK1.8 + Jenkins2.134

故障處理過程

解決nginx訪問403的問題

通過 Jenkins 調用varian正常部署了一個靜態項目（純html，css，js等靜態資源），通過負載均衡訪問容器集群（參考上邊架構圖），發現頁面樣式無法載入，瀏覽器按F12調出控制台發現個CSS文件返回403狀態：

chrome F12調試

web服務用的nginx，腦海里迅速過了一遍什麼情況下nginx會返回403：

nginx配置了白名單，client端訪問的IP不在白名單內

訪問的路徑是個目錄，而nginx配置了禁止列目錄

訪問的路徑是個文件，但nginx服務配置的用戶和用戶組對文件沒有讀取許可權

目錄索引index 配置錯誤，例如你的目錄下只有index.html，你卻配置了index.shmtl或index.php等等

index index.shtml index.php;

常見的有以上問題會導致nginx返回403，迅速排查了一下，發現就是許可權的問題導致的，nginx配置的用戶和用戶組為www-data，而css文件的屬主屬組都是root，且其他用戶沒有任何許可權：

這裡再詳細講解下linux下的文件許可權，以上邊的csl.css文件為例：

-rw-r----- 1 root root 7.9K Jul 24 12:34 csl.css

以空格分割

第一段-rw-r——-10個字元定義了文件的許可權
- 第一個字元，這裡為-代表這是一個文件，還會看到像d代表目錄、l代表連接
- 剩下九個字元，每三個一組，第2-4個字元代表屬主許可權，第5-7個字元代表屬組許可權，第8-10個字元代表其他用戶的許可權
- 其中每一組三個字元分別為r、w、x，用數字表示r=4、w=2、x=1，分別代表讀、寫、執行許可權，如果這個字元有值表明有這個許可權，例如上邊css文件的許可權就為屬主有rw讀寫許可權，屬組只有r許可權，其他用戶沒有許可權
第二段為一個數字，表示文件的連接數
第三段root表示用戶的屬主為root
第四段root表示用戶的屬組也為root
第五段則表示文件大小
後邊三段為修改時間
最後一段為文件名

tomcat8 UMASK

經過反覆測試，發現我直接在linux下通過控制台執行python腳本的方式發布部署最終文件許可權正常，但是同樣的腳本經過Jenkins執行後許可權就不對了。

控制台執行跟Jenkins執行有什麼區別？賬號不一樣啊，遂把jenkins項目、tomcat文件都改成屬主屬組都為root重新執行，發現還是一樣的結果。

再想想還有哪裡不對，這個css文件是程序生成的，生成的文件許可權不對，umask！這個詞突然蹦出來，對，應該就是umask，他控制了生成新文件的許可權。

簡單介紹下什麼是umask：

umask值用來設置用戶在創建文件時的默認許可權，跟設置文件許可權命令chmod是相對的，總共四位，不過我們通常只用後三位，同樣對應屬主屬組以及其他用戶的許可權，例如你的賬號umask值為0022（可直接通過umask命令查看）。

此時你創建的文件許可權默認為644（文件初始的最高許可權為666，umask設置為022，那麼最終的許可權為：6-0,6-2,6-2=644。

當然有人說文件的許可權最高是777，是的沒錯，但我們說的是默認許可權，默認許可權是由umask決定的，umask設置為000時文件的許可權就是666，文件夾許可權777），此時創建的目錄許可權為755（目錄的最高許可權為777，umask設置為022，那麼最終的許可權為7-0,7-2,7-2=755）。

查了root用戶的umask、jenkins用戶的umask，都為0022，沒問題呀，並且登錄這兩個賬號創建了新文件許可權也都正常，就剩下一種情況了Jenkins！

Jenkins沒有地方可以給配置UMASK，Jenkins跑在tomcat容器里，老版本的varian也有相似的處理邏輯一直沒問題，本次升級了tomcat8，難道tomcat8更新了UMASK？半信半疑的看了下，果然！tomcat8的umask默認改成了0027，麻溜的改成了0022，問題順利解決！