Re: [請益] 如何同時更新多台Server內的DB及APP

[qrtt1 (有些事，有時候。。。)]

因為有看到一些關鍵字，還是單獨回一篇好了。

※ 引述《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
推 kewang: 推好文，大家在用 buzzword 之前，還是要了解本質到底做了
→ kewang: 什麼
推 alihue: 推
※ 編輯: qrtt1 (36.231.141.56), 11/17/2018 22:21:00
推 johnny94: 敢問 qrtt1 在哪高就，真想跟有這種想法的人一起工作XD
偏鄉的小公司 (咦!?
※ 編輯: qrtt1 (36.231.141.56), 11/17/2018 22:36:27
推 f496328mm: 推推優質好文
推 ian90911: 推好文
推 chocopie: 推
推 umum29: 推
推 genius945: 推
推 walker088: 感謝q大的回覆，真的是獲益良多，確實如q大所說沒有經
→ walker088: 過足夠測試的自動部署在方便的同時也會把bug通通部署
→ walker088: 上去。目前這邊團隊很小在部署測試甚至版本文件等等部
→ walker088: 分幾乎是沒有任何固定的流程或規範，只求系統能動而已
→ walker088: 。昨天看完眾多大大們聽到的技術關鍵字看了一下文件及
→ walker088: 教學後也有了一些大致的概念，但確實會需要一個完整的
→ walker088: 方案來取得自動化 安全以及災害復原的平衡。非常感謝q
→ walker088: 大的提醒！
→ walker088: 阿忘了回應struts2的部分XD, 其實我個人也不大喜歡...
→ walker088: , 但因為系統是我來之前就寫好一陣子的且原本對java也
→ walker088: 不大熟, 要打掉重構成比較新的架構(e.g., spring boot
→ walker088: )的話需要一點決心... 而且話說這個系統本來就完全沒
→ walker088: 有任何文件, 大家在部署時候環境版本也都沒統一, 我也
→ walker088: 是來這邊邊摸邊寫文件跟做自動化這樣orz
推 wanlinlin: 推
推 ChoDino: 收藏！
→ rocwild: 問CI/CD相關問題得到DR回答，帥。
推 unknow: 感謝分享~QAQ
→ remmurds: 每次一有類似議題馬上就有人跳出來喊docker
→ remmurds: 都不膩嗎？
推 pig840502: 推
推 johnny94: 推remmurds。而且docker跟原PO問的問題根本沒半點關係
→ Weky: Docker牆都快倒了 別再docker了
推 Csongs: 樓上怎說