Re: [請益] 自動化佈署(Chef, Ansible, Salt)

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

※ 引述《Sanbeishuu (三杯鼠)》之銘言：
: 請問主流的幾款自動化佈署軟體有無較適合單純的update某個web application的呢?
                [--------]                    [-----------------------]
                                  update 這確實很容易，但事情不是只有 update

                你現在只想到 {自動化, 部署}

                不是真的 {自動化部署} 完整的思維應該是 delivery pipeline

                自動化不是必要的，但要完全「非人工」介入，

                並讓每一個程序可以被追蹤，得付出額外的努力。

                當你真的做到「完善」的時候，

                你要做的事就不是單純你現在描述的這些內容了。


                可以先看個入門學，培養一下概念

                http://www.books.com.tw/products/0010653820
                https://www.thoughtworks.com/continuous-delivery


                (由於成書至今有些年份，工具可能改朝換代，

                 或 DVCS 的接受度有變，那就依自己的情境代換一下吧。)

: 一開始試了Jenkins，發現他好像不是這樣的用途。後來才發現應該是其他的像是
: Puppet, Chef, SaltStack, Ansible, Juju?

        Jenkins 最初大家拿它來做測試為主，

        並因為是基於 jvm 為主的應用程式，所以拿它來控制各種平台的活動

        實在非常方便，所以才有用它的 agent 在常見的 Linux, Windows, OSX

        上配合與不同的 Browser 組合互相試測（配合 selenium 更是如虎添翼）

        甚至到現在，加上 android device 或 iOS device 的自動化測試依然也適用。


        對它來說，工作的「單位」都是 Job，只要有安裝上 java agent

        （在防火牆內還可以透過 JNLP 由 node 上連回 jenkins master）

        就能輕鬆遞送要做的工作。


        Jenkins 比較適合在 node 數固定，且混雜異質平態，需高度客製化的情境。

        因為 "Job" 的內容很多變，可以是 Ant Job、Maven Job、Gradle Job

        或沒限制你寫什麼的 FreeStyle Job，你想改什麼，或呼叫端遠指令都做得到。

        不過要寫成這樣，已經跟「高度」客製化沒什麼差別了啊。


        （這隱含著，你目標的環境並沒有「整理」成較一致的情況）


        不過，到了 2.x 要準備發佈的這個時代，加上「雲端」與

        Continuous Delivery 概念與 DevOps 哲學觀的推擠，

        它開始將 workflow 的概念合併改名字為 Delivery Pipeline 的 Pipeline。

        也就是你一個完整的軟體開發流程的「管線 (pipeline)」是怎麼串起來的


        1. 開發者把程式送往 VCS

        2. VCS 的程式被拿來 Build 成 Artifact

        3. Artifact 被拿來跑單元測試

        4. Artifact 加上 Configuration 丟上 UAT 跑整合測試

        5. UAT 跑過後，送上 Staging 跑整合測試與煙霧測試(smoke test)

        6. 通過各種測後，進行 release 的 workflow

        這整個 workflow 的每一階段都是 1 個 pipeline

        pipeline 內可以是另一個 pipeline 或實際執行的步驟。

        且每 1 輪的 workflow 的發起都會對上 VCS 的 revision



        release 的 workflow 會是某個標示通過測試的 artifact

        （你會有 jenkins build number 與知道它是哪個 revision）

        以你的情況，可能是某個 war 或 jar

        會在 prod 上 deploy 並進行煙霧測試，確定狀態良好後開始服務

        不然就維持舊的版本


        ==========================================================


        Puppet, Chef, SaltStack, Ansible 則是不同的動機而起的，

        雖然目前比較「紅」的詞是 DevOps，但應該回到最初的想法去看它

        他們該做的是 Configuration Management 這個工作。


        但有個尷尬的問題是，你得先面對一個「選擇題」。

        在 Continuous Delivery 書上，它的想法是

        一個應用程式的良好運作是建立在 {組態設定、程式、資料} 三者都正確的情況

        並且認為 {組態設定} 應獨位於程式，它的建議是 {組態設定}

        不會包含在 Build 與 Package 內，應該獨立於它之外。

        以這個邏輯來說，應該上組態的時間點在 Deploy 或 Provision 的時候。



        而 Puppet, Chef, SaltStack, Ansible 正好是在做這件事的最佳助手

        能幫檢查設定檔在不在、程式的狀態是不是在期望的狀態等等

        他們的用法多為「描述一種最終的狀態」並且試著修正不合預期的狀態



        尷尬的部分是，在 Java EE 的規範是把 {組態設定} 也封狀進 WAR 內的

        我並不會說書上那麼建議，就一定要遵守，最適合的情況，

        只有身處於那個工作場域的人自己知道。

        以我目前的情境是比較傾向於把 {組態設定} 包進去的，

        對我來說，來自同一個 revision 建出來的東西好追蹤比較重要

        同一個 team 的開發者，不用多認識其他 tool 就能建出一樣的結果

        這樣也同時能減少 {組態設定} 管理不當的意外。

        因為二組 repo 可能會不好對上，

        不管是 cfg 的 revision 沒跟上，或是 project 的 revison 沒跟上，

        都可能有意外發生，或是 deploy process 失敗了，因為要 deploy 二次，

        一次是 project 本身，一次是 {組態設定} 本身。



        由於 DevOps tool 自己另一組 VCS repo 管理，

        若是硬分割至各專案內，就變得難以看清楚

        Infrastructure as Code 的全貌，除非剛好它們有機會共用一個 repo

        且不會意外形成 duplicated code 那會是個較佳的型式。

        (或是區分開來系統層面的 Automation 與專案元件的區分開來也是個辦法)



        另外，不包進去，也不另外透過 deploy 程序來更新組態設定的話，

        第 3 條路就是 service discovery 的方法了

        (應該是書上第 2 部，講組態管理有提到這概念)，

        通常就是跑個 agent 讓你問現在的設定。

        像 EC2 在機器內部提供的 metadata
        http://amzn.to/2cLJW4a


        現在有 https://www.consul.io/ 這類的工具能做到

        （但以你的情況需求 "portable" 大概不會採用 :P）

        用這東西確實能讓你把組態抽出來，不過實際是否真的需要那麼「彈性」

        是存疑的，過度的彈性與靈活，會造成「設置困難」，

        每個選項間可能又有相依關係，這也許會搞死新進的開發者，

        或是終於使用者根本無法利用這些「彈性」的設計。


: 目前看起來1跟2是Ruby派，3跟4是Python派，小弟是純Java派，所以沒特別偏好。
: 但如果可以的話是傾向Py派，但其實各款的script好像也不一定是用Py或Ruby寫..
: 主要使用情境如下:
: 1. Standalone & portable
:    希望是可以單純locally的去run，run這一台機器本身的deployment。
:    貌似這類軟體都是為了cloud management，所以都有server/client的架構。
:    目前只先略略survey了Chef，應該是有單純Chef-client跑CookBook的功能。
:    SaltStack有看到masterless跟standalone的documentation的樣子。
:    另外還希望這是可以portable的，也就是我可以調整好script後打包起來，
:    然後交給客戶在on-premises的情境下，double click去完成deployment。

        要讓客戶去 double-click 不覺得跟標題的「自動化」有點違悖嗎 :P

        或許我該先忘記 double-click 或是「自動化」其中一個提前。

        假設，我捨棄了「自動化」，讓客戶 double-click 的話，

        又能 portable、又不可以另外裝些什麼軟體

        那我該做些什麼呢？

        弄個 executable JAR 做：

        1. 下載最新的 WAR 回來（executable JAR 內知道 revsion => artifact）

        2. 開一台 embedded Tomcat 跑這個 WAR (如果要改組態的話，也改吧)

        3. 開始做 smoke test 確認重要的功能都可以動 (至少 DB 要連得上)

        4. 如果有問題就，send log 回來

        5. 如果沒問題就換上新版的至 prod


        (這其實沒有像一些不上 store 的 andoird app 給你個 apk

         它是讓你下載另一個 apk 用的!?)



        如果我捨棄的是 double click。首先，為什麼要捨棄 double click 呢！？

        因為客服可能收到了你「最新」的安裝檔，但卻執行了「舊的」安裝檔，

        然後再寫信問你為什麼不 work。

        其實 double click 不是主因，是人工判斷的品質差異比較大，

        有可能他半夜被 call 來換檔（可能是加班，或不同時區），不小心點錯了

        也可能是他沒有點錯，但我方給錯了版本。

        至少，把品質放在人少的那一方比較好控制，

        你可以把那個要 double click 的檔變成 windows service，

        定期去查有沒有新的更新，有的話就執行更新程式

        (這不就是 windows update 嗎？)


        PS. 千萬不要把更新程式與 tomcat 綁在一起

            你無法預知，你上新版後 tomcat 是不是會被你弄死

            萬一綁在一起了，他們就只好殉情了

        (其實 AWS 的 Beanstalk 也是弄個 hostmanager 的 agnet 做這件事啊)


        PS. 不管你選擇的是什麼，都得能方便的知道使用者現行的版本

            例如在 http response 加上特殊 header 標上各 component 的 revision


: 2. 只單純的deploy一個Java web application到tomcat
:    沒有要做複雜的server setup跟provisioning。想達到的其實只是單純的
:    upgrade某個web application而已。所以整個flow有點類似以下這樣
:    已經有一個application跑在tomcat。該application有a.xml跟b.properties檔案
:    a.xml的內容會類似如下
:            <Property>
:                <Name>ServerURL</Name>
:                <Value>192.168.1.2</Value>
:            </Property>
:    b.properties的內容會類似如下
:            database.host=192.168.112.25
:            database.port=5432
:    有一個新的版本出來了，當然他是一個war檔。war檔內一樣有a.xml跟b.properties
:    只是這時war檔內的這些configure値會是default狀態。例如:
:            <Property>
:                <Name>ServerURL</Name>
:                <Value>localhost</Value>
:            </Property>
:            database.host=127.0.0.1
:            database.port=5432
:    自動化的把war檔解壓，將a.xml跟b.properties內容與正在運行的
:    application有不同的地方做更改。然後可能必須在壓回去war包，
:    call tomcat的rest API去進行deploy，如此將web app upgrade，
:    又不需要人工去處理這些application properties的設定値。


        如果你只是要簡單的換 IP ... 那不如改 local host 對應的設定

        C:\Windows\System32\drivers\etc\hosts

: 3. Windows platform
:    Tomcat跑在Windows平台上(Win7, Win10, Win Server 2008, 2012 etc..)
:    所以等於是master跟client或者說standalone的運行是在Windows平台上。
:    Chef有Windows的msi安裝檔，還沒確定是否可以portable的包起來。
:    SaltStack的getting started doc都是Linux版本的範例..

        很遺憾的，這些程式最初的開發者都不是 Windows User。

        即使用提供，因為開發者人不夠多，用的人也不夠多

        待「踩雷」的點應該很多，需要有「愛」才用得下去，

        或是加入改善它們的行列吧！

: 4. Free~
:    目前看到Chef, Ansible, SaltStack都有付費版本或者提供SaaS。
:    但應該都有真正的freeware版吧? Ansible看不太出來
:    只有一個Ansible Tower Free trial
: 不知道有沒有大大可以建議一下哪一款比較適合簡單的達到這個的佈署呢?
: 感謝


        看來看去，是前一篇大大自己 deploy tool 對你來說最適合。

        或是問問其他 windows 深度使用的管理者，看看有沒有好招！？

        我們現行的 deploy tool 也跟他相似，不過是仿 AWS Beanstalk

        指定 revision 後，deploy 至各機器上

        （但沒有做 agent 是 rsync 去遞送 + ssh remote command）


        不過隨著系統的環境，與 project 整理的越來越一致，

        之後應該會轉移至 ansible 上，透過它 deploy。



--
JCConf 工商服務
https://www.facebook.com/jcconf/posts/974947969317750

JCConf 2016 售票至 10/9 (日) 結束呦 :D

報名網址：http://twjug.kktix.cc/events/jcconf2016-register
議程網址：http://jcconf.tw/2016/

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 211.21.157.224
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1475483798.A.9C0.html
推 pttworld: 　
→ pttworld: 本質問題。交給客戶使用可能是客戶不清楚。
→ pttworld: 德瑞克的似乎自己在用，未顯示部署失敗的處理。
我想是我沒表達清楚，不是說要用德瑞克的實作，而是如德瑞克般自行客制。
→ Lordaeron: 搞哪麼多工具，看起來不如寫一寫比較快。
推 tangblack: 推，看下來覺得寫很清楚，回到第一頁看作者原來是qrtt1
推 Hevak: 推，這篇觀念好棒
推 lairrol: 優質文，整套自動化下來確實很美好，實際弄真的很複雜..
推 ian90911: 推好文
推 Ekmund: 優質
※ 編輯: qrtt1 (211.21.157.224), 10/04/2016 11:41:58
推 chung928: 優文必推
推 DeathWatch: 推