Re: [請益] 自動化佈署(Chef, Ansible, Salt)
其他部分恕刪，以免文章過長
: ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1475483798.A.9C0.html
: 推 pttworld: 10/03 17:11
: → pttworld: 本質問題。交給客戶使用可能是客戶不清楚。 10/03 17:12
: → pttworld: 德瑞克的似乎自己在用，未顯示部署失敗的處理。 10/03 17:13
pttworld大大也未免太小看我Hsu某人了吧（哈哈，別生氣，開個玩笑）
: → Lordaeron: 搞哪麼多工具，看起來不如寫一寫比較快。 10/03 17:34
: 推 tangblack: 推，看下來覺得寫很清楚，回到第一頁看作者原來是qrtt1 10/03 19:54
: 推 Hevak: 推，這篇觀念好棒 10/03 21:50
部署失敗或生效失敗的情況，這當然有考慮在我之前分享的自幹部署平台裡面。
整個上線程序可以簡單畫分為三個不同階段
1. 建置
2. 部署
3. 生效
建置失敗，主要是開發者自己的問題，或者是位在DH系統上設定模組間的依賴關係
（我之前提過，模組之間的依賴關係跟每個開發者本地的build.gradle或是
gradle.properties沒有關係）沒有設定正確，才會導致建置失敗，這一點會反應
在平台的查詢結果上，並且透過整合Activity BPM Workflow跟企業內部訊息通報作業
告知開發人員進行修正。
到了部署階段之後的所有過程，我都有在Graylog上面設定stream alert並整合
Slack，所以哪一台傳輸失敗我們都可以近乎在第一時間知道哪一台在deploy的
過程中失敗了，需要人工介入處理，通常會發生這種情況都是網路或是硬體出了
問題，導致SFTP/SSH的執行過程中斷，這很難透過任何方式自動化。
等到叢集內完成部署，系統會開始進行生效作業，我在生效作業設計了兩種不同
的作業方式，分別是rolling upgrade與Tomcat Parallel Deployment。
我先講前者，在公司內的資訊系統可以分為多個不同的叢集，每個叢集運作一個
系統，每個系統又可以分為1~多個模組，部署是以模組為單位，而生效是以叢集
來進行。
每個叢集之下的伺服器又可以分為幾個群組，每個群組內的伺服器是為一體的，
restart是一起進行。
每個系統都會有一個heartbeat/healthy check URL，這個URL是一個Spring MVC
的bean，他會呼叫DAO bean執行dummy query確保連線跟Bean都運作正確而且完成
bootstrap。
DH會先更動load balancer（Apache HTTPD或HAProxy，測試環境用，正式環境用F5）
，然後開始依序重啟叢集內每個群組的所有伺服器，然後每隔一小段時間測試每個
伺服器的heartbeat/healthy check URL，等到所有伺服器都測試通過之後，才會繼續
下一群伺服器，以此類推。
在這過程中，因為有Graylog跟Stream Alert功能的幫助，我們都可以即時知道生效
狀態，比如是否生效時間超過平常預期，bean的載入或初始化錯誤，無法初始化資料庫
連線的，這些都會被抓到然後人再介入處理。
若是使用Tomcat Parallel Deploy的方式，其實也是可以分成多個群組輪流進行平行部署
，但我沒有這樣做，也倒是沒有什麼問題發生，平行部署如果新的Spring Context run
不起來（bean有錯或無法連線到資料都會造成context load fail），原來的application
不會被undeploy，我們一樣可以透過Graylog第一時間知道問題發生。
以上部署過程只要不要真的發生一些問題，目前我們一整天幾乎都不用連線到伺服器上
處理任何問題，所有部署都可以讓開發人員自己來做。
各位應該可以發現我提到的部署過程中缺少一段很嚴重，前一位大大有提過的：Testing
，建置完成之後應該做Unit Testing，Deploy到Test之後應該要做Integration Testing
.....等等每個階段都有該做的Testing，但我把整個檢查過程縮減到只靠healthy check
，這是有風險的。
但這是不得不為，由於人員因素，絕大多數同仁不會也不寫testing program，如果開發
人員的程度不能夠把unit test跟integration test自動化，那過程當中就不得不有大量
人為的參與，integration test交給同仁自己做並且相信他們做的結果。
種種權衡之下，我已經盡力處理部署或生效失敗的情況，並避免因為這樣的情況發生造
成使用者的不良體驗。
走到自幹deploy platform也是不得不為的做法，當你要考慮整合一切其他的流程，
像是Sonarqube，Doxygen跟我們上線時會自動從Gitlab中撈出一些程式異動資訊寫到
資料庫裡面，當必須對手上現成工具進行大量客製化的時候才能達到你的目標時，與其
把時間花在那麼多客製化上面，不如從頭打造一個量身定做的系統。
--
～四十八個德瑞克～http://blog.derekhsu.homeip.net
馬皇本紀：http://blog.derekhsu.homeip.net/2009/08/821
藍澤光的身世之謎：http://blog.derekhsu.homeip.net/2010/09/1610
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 112.105.254.212
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1475511300.A.8AC.html
推
10/04 05:05, , 1F
10/04 05:05, 1F
→
10/04 05:06, , 2F
10/04 05:06, 2F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 4 之 4 篇)：