Re: [請益] 如何同時更新多台Server內的DB及APP
因為有看到一些關鍵字,還是單獨回一篇好了。
※ 引述《walker088 (巴拉圭魯蛇)》之銘言:
: 各位年薪百萬大大們好
: 小魯我是目前在巴拉圭的替代役男
: 剛開始在地球另一端摳頂大概三週而已
: 工作的計畫是協助他們國家醫院醫療資訊系統的開發&維護
: 使用的技術如下:
: Backend: Java 8, Struts2, Tomcat 8.5
[-----]
struts 2 必須死
http://bit.ly/2HYz8vB
: Database: PostgreSQL-9.4
: Platform: CentOS 7
: Others: Flyway, Gradle
: 這邊想跟各位大大請益問有關DevOps的問題
: 這裡開始使用我們系統的醫院目前都有獨立的伺服器
: 因此當我們的APP(Java)或DB有做修改後
: 他們目前是逐台Server做手動更新
: 滿浪費時間的而且未來推廣到更大量醫院時候很慘
: 幾分鐘前老闆讓我找個方法可以同時更新所有的Server
這段配合著你在推文中想的情境來看
『
量很大且人力不足的話 (e.g.,300台機器 5人的team)
也會是傾向逐台手動嗎? 不會是像MS那樣直接更新?
』
假設,程式真的寫得糟糕到不行。
每 1 台只能同時有 100 人在 web 上操作。
那你是打算要同時服務 3 萬人嗎?
這例子其實不太合理,但也是那是你因為焦慮而隨意說說的內容。
真的到你得服務麼多人時,早不是這樣的架構了。
(團隊編制應該也很不同)
: 這邊因為基本上更新主要有兩個任務:
: 1. 寫好更新DB的sql後丟上Server用Flyway執行 (或直接psql吃.sql)
: 2. 開發出新的版本後包成 .war 檔丟進Server的Tomcat
由於你才剛進入團隊 3 週,也許別急著要做出成果來。
先別管 DevOps 是什麼東東,
你目前在做的事情本質上是自動化部署
(還談不上 CI/CD 的邊,因為有些基礎建設並不存在)
依你的方法是可行的,BUT....
: ----------------------以下是土法煉鋼--------------------------
: 目前直覺想到的解法是寫個簡單的輕量TCP Server放在醫院們的Server上
: 接受可以通過一些檢查(e.g., rsa)的TCP client的請求後執行上面兩個更新的動作
: -------------------------煉鋼完畢-----------------------------
我們可以隨意挑出幾個目前廣泛運用在 DevOps 或 CI/CD 工具
來做到你想要做的事,但輕易地跟你說
『
OOO 可以做到你想做的 XXX
』
是個便宜的答案,你可以暫時間內獲得能動的解答。
但對大家都沒有益處,因為基礎建設不足可能引發的災難遠大於效益。
自動化的優點就是省去人工的時間,
並且它會非常地快速完工 (相較於人類的手速來說)
若沒有基本的 CI (也可能沒有能跑的 test case)
那麼 Bug 或程式缺陷也會被迅速地部署上去。
到時你想喊停可能都還來不及啊!
這就是為什麼,我的推文是問『災難回復』的策略與演練呢?
你們團隊的 plan 是什麼?有沒有 plan 來幾個小問題就能先心裡有個底了
先試著回答一些簡單地問題:
1. 如果所有的 server 與 db,不小心因為天災、人禍而消失
有辦法輕易地重建回來嗎?
2. 有定期備份 db 資料嗎?上一次備份的時間是什麼時候?
3. 有定期試著由備份的 db 資料,做回復並驗證內容的正確性嗎?
4. 在基礎系統設定完成後 (像是基本的 OS, Network, Account)
4.1 安裝 db 到資料回存完要多久時間? (別忘了算取回備份的時間)
4.2 安裝相關 server 並佈署完應用程式,能開始對使用者服務要多久
4.3 整個 4 是否有『計劃』並完整理處理過一輪
5. 上述的每一項目是否有 RCA 的 log 記錄,不管是專門的文件或 issue 內
供後人做 trouble shooting 的參考
你的回答有幾種可能:
1. 集合團隊所有人『腦中』的智慧有辦法完成上面的每一件事
2. 已有文件來回答上面的每一項問題(或部分的問題)
2.1 通常是有 4 的文件,但其他項目不清楚
2.2 假設有文件,但可能 out of date 已久,
它可能是先前剛建 team 時寫下來的,但後來忙於日常開發就不再更新
3. 針對 server 環境的初始化已有 provision 腳本
(例如寫成 ansible playbook)
(你絕不會想要反覆地去搞 CentOS 的 selinux 設定的,
或程式跑一陣子發現 ulimit 忘了改,而開不出檔案)
4. 針對應用程式 deployment 已使用自動化工具
(例如寫成 ansible playbook)
5. 不僅自動化了應用程式部署,並在那之前 release 版本皆通過足夠的測試
5.1 基本的單元測試
5.2 配合外部環境的整合測試
5.3 針對使用者視角的 e2e 測試
................................................
雖然是說問幾個簡單的問題,不知不覺就寫了許多 (汗
: 但因為並不熟悉Dev-Ops的領域
: 怕這樣土法煉鋼未來會比較麻煩
: 畢竟役期只有接近一年,結束後就會返台了
一年其實不短,真正該導入的不是 tool 而是 mindset
當 mindset 對了,要挑什麼工具只是依情境判斷的問題。
先前的題問,其實還在開發階段的事情,還沒提到維運部的事。
monitoring 又是另一個重要的主題,假設你真的有 300 台!?
你真的會想一台一台上去看 log 或看誰硬碟滿了要清嗎!?
: 為了避免留下困擾給之後的人
: 想詢問是否有比較主流 or 有制度 or未來好管理擴充的做法
: 有開源工具或者相關關鍵字的話就更好不過了!
: 感恩感恩
Continuous Delivery
https://amzn.to/2KcrjUy
http://bit.ly/2K8o14y
Effective DevOps
https://amzn.to/2K8ouDQ
http://bit.ly/2KaETI6
想起先前也有回過類似的主題
https://www.ptt.cc/bbs/Soft_Job/M.1475483798.A.9C0.html
另外,關於 Tomcat 有個實用的功能
Parallel deployment
http://bit.ly/2KaP3bD
可以針對同 1 個 context 部署多個版本,利用它來達成
zero downtime deployment 很好用。
然後,如果程式碼不多,
或能切出新功能是用不同的 tech stack 的話
struts 必須死!
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.141.56
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1542462776.A.040.html
推
11/17 22:04,
5年前
, 1F
11/17 22:04, 1F
→
11/17 22:04,
5年前
, 2F
11/17 22:04, 2F
推
11/17 22:16,
5年前
, 3F
11/17 22:16, 3F
※ 編輯: qrtt1 (36.231.141.56), 11/17/2018 22:21:00
推
11/17 22:34,
5年前
, 4F
11/17 22:34, 4F
偏鄉的小公司 (咦!?
※ 編輯: qrtt1 (36.231.141.56), 11/17/2018 22:36:27
推
11/18 00:19,
5年前
, 5F
11/18 00:19, 5F
推
11/18 00:25,
5年前
, 6F
11/18 00:25, 6F
推
11/18 01:05,
5年前
, 7F
11/18 01:05, 7F
推
11/18 01:09,
5年前
, 8F
11/18 01:09, 8F
推
11/18 01:46,
5年前
, 9F
11/18 01:46, 9F
推
11/18 06:50,
5年前
, 10F
11/18 06:50, 10F
→
11/18 06:50,
5年前
, 11F
11/18 06:50, 11F
→
11/18 06:50,
5年前
, 12F
11/18 06:50, 12F
→
11/18 06:50,
5年前
, 13F
11/18 06:50, 13F
→
11/18 06:50,
5年前
, 14F
11/18 06:50, 14F
→
11/18 06:50,
5年前
, 15F
11/18 06:50, 15F
→
11/18 06:50,
5年前
, 16F
11/18 06:50, 16F
→
11/18 06:50,
5年前
, 17F
11/18 06:50, 17F
→
11/18 06:55,
5年前
, 18F
11/18 06:55, 18F
→
11/18 06:55,
5年前
, 19F
11/18 06:55, 19F
→
11/18 06:55,
5年前
, 20F
11/18 06:55, 20F
→
11/18 06:55,
5年前
, 21F
11/18 06:55, 21F
→
11/18 06:55,
5年前
, 22F
11/18 06:55, 22F
→
11/18 06:55,
5年前
, 23F
11/18 06:55, 23F
推
11/18 07:17,
5年前
, 24F
11/18 07:17, 24F
推
11/18 11:22,
5年前
, 25F
11/18 11:22, 25F
→
11/18 11:53,
5年前
, 26F
11/18 11:53, 26F
推
11/18 13:40,
5年前
, 27F
11/18 13:40, 27F
→
11/18 16:54,
5年前
, 28F
11/18 16:54, 28F
→
11/18 16:54,
5年前
, 29F
11/18 16:54, 29F
推
11/18 17:51,
5年前
, 30F
11/18 17:51, 30F
推
11/19 01:00,
5年前
, 31F
11/19 01:00, 31F
→
11/19 19:01,
5年前
, 32F
11/19 19:01, 32F
推
11/19 23:45,
5年前
, 33F
11/19 23:45, 33F
討論串 (同標題文章)
本文引述了以下文章的的內容:
完整討論串 (本文為第 2 之 2 篇):