※ 引述《dream1124 (全新開始)》之銘言： : 請問大家有使用過 Puppet, Chef, Ansible, Salt 這些組態管理與配置工具的經驗嗎？ : (configuration management and orchestration tools) 簡單地說，使用這些工具，避不了有擴充他們的時候 那些時候，即使你不是自己動手寫他們的 plugin 那也要找別人的來用 這時你得面對的是他們的 source code 實做的語言。 這樣就能粗略地分為二類： 偏好 Ruby 的由 Chef, Puppet 下手 偏好 Python 的由 Ansible, Salt 下手。 (至少在選擇困難的議題上，你已省力了 50%) : 我覺得同事部署應用程式的方法實在太辛苦了，希望能幫他們想點辦法。 : 據我查的資料，上列方案至少都能夠批次自動調整作業系統的設定， : 有些甚至還有中央控制的伺服器可以排程配置很多電腦的組態設定。 : 但是各家廠商宣傳文件和比較表令我看得頭昏眼花，有些問題也沒找到答案， 依據過去你在版上的討論，加上文末提到的 Java。 我猜測是要部署 Java Web Application 為主， 有點難理解這類的應用程式為何會難部署， 你可能得再補充實際上的『痛點』才能讓有解的人給予建議 舉例來說： 純 Servlet Container 像 Tomcat 有 RESTful API 能更新 較大一點的 Application Server 像 Weblogic 有 WLST 介面 能用 jython 或 ANT 來更新程式、變更設定... : 請問大家方便解答下列的疑惑嗎？ : 1. 如果系統的使用量不會經常變動，管理者多半不用經常調整叢集裡的伺服器配置， : 甚至有許多系統不是叢集，這樣的話導入這類工具的效益會不會很差呢？ : 據我所知，這些工具的操作與管理介面似乎相當不一致， : 我們恐怕難以大幅藉著過去的軟體使用經驗快速評估任何一種方案， : 只能一頭栽進去，花費大量時間了解狀況。 : 另外，雖然公司未來有可能會部署應用程式到國外的資料中心， : 但系統使用量多半相當穩定，可能沒有擴充性(scalability)的問題。 : 因為有這些考量，使我不太確定是否值得導入這類工具。 先試著回想一個問題， 上一次『從無到有』建出完整的系統，所有機器是什麼時候的事了？ 要建出完整的系統，從一個空的 Server 安裝好 OS 後， 需要多少步驟、時間才能完工呢？ 而這些安裝的細節是怎麼保存、怎麼與現狀同步的？ 在過去，我們是依賴著一代一代傳下來的交接文件， 隨著 Server Admin 換人，或新專案啟動多少會影目前的配置 文件能不能近可能接近與『現況』同步的狀態是相當大的挑戰 PS. scale in/out 大部分是架構設計的問題， 部署工具的角色主要在： 1. 建出一個基礎只差修正 config 或更新部分應用程式 2. 異動管理（部分程式更新或設定變更） 不太有時間讓你要 scale out 時用 deploy tool 慢慢從無到有裝起來 通常會包成能比較快速啟動的型式（VM 的 image） 或是預先好的安裝包（例如 RPM, DEB） http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html : 2. 請問他們目前跟持續整合伺服器結合的狀況怎麼樣？ : 我知道 ansible 有 jenkins 的外掛，但是不清楚其他的組態管理工具 : 有沒有現成的整合工具或套件，使它能夠跟主流的持續整合系統一起 : 實現高度自動化的持續部署機制？ 莫驚慌、莫害怕。 即使他們什麼外掛都沒有，還有最終一招『呼叫外部程式』 總可以呼叫他們的 command 去做事唄 :) : 3. 請問像 kubernetes 這樣的工具跟前面那些組態管理工具有什麼不同？ : 差別是不是在組態管理的對象...前四樣是作業系統，kubernetes則是容器呢？ : http://blog.kubernetes.io/ k8s 是 docker clustering system 跟前面的東西的用途是相當的遠的！ : 4. 請問有沒有人試過在開發人員行情於 42k 左右之團隊引入 Docker 建置 : 個人的開發環境呢？ 不知道這些人能否順利上手？ 會不會遇到很特殊的問題？ : 不知道能否期待使用 windows 10 的 docker 將新人建置 java 開發環境的時間 : 從三天縮減至一天？ : 在此先謝謝大家分享的經驗！ 也歡迎私信交流！ 開發人員的行情 跟 做這些事沒有關係 開發人員的行情 跟 做這些事沒有關係 開發人員的行情 跟 做這些事沒有關係 不管薪水多少，得要為自己謀福利。 包含部署應用程式的舒適感 與 維護部署應用程式的應用程式的便利性 即使 Docker 的 native support 已經有宣傳能在 Windows, OSX 使用 但要到穩定好用不確定要再等多久， 而你的情境多是 java 為主的話，要新人快速地從無到有建立開發環境 在有提供手冊指引的話，沒道理一天搞不定啊 （一定是有什麼我們所不知道的細節沒談到） ============================================================== 回頭來講為何要支持導入這些工具， 長遠的目標從開發環境到部署環境（product, staging, testing) 都期望朝向 Infrastructure as Code 的目標前進 具體地描述是說，我在 server 上改了什麼（更加哪些軟體或防火牆設定） 我能簡單地在版本控制系統裡 diff 或 blame 一下就知道發生了什麼事 當某些配置有問題時，我可以平行的建出一套一模一樣來模擬它 或當有人手殘下了 rm -rf / 時，我們在較短的時間， 以沒那麼慌亂的步調來進行重建的工作， 不會因為當時『壓力山大』而再做了更多蠢事。 使用 code 代替不時 out of date 的 operation 文件， 在人員異動時，也比較沒有麻煩，大家一同執行一下程式 雙方結果都一樣後，那再說明一特例需要微調的部分即可。 ============================================================== 大致理解 Infrastructure as Code 之後， 談另一個概念是 immutable server，你只會部署 1 次 那次部分之後上面的所有東西都不會再變了（除了資料與暫存狀態） 有新的變更就得再重新生一份 image 出來部署 這與利用 configuration management tool 來持續同步 server 到最新的狀態是不太一樣的『風格』 （注意，你也可以使用 configuration management tool 來做， 只是它們只有同步第 1 次，之後都不變了，並封裝起來使用） 這風格的優點是養 server，不再像養寵物。 寵物生病了要醫好他，愛他一生一世。 immutable server 壞了就把舊的丟棄，生一份新的取而代之。 http://martinfowler.com/bliki/ImmutableServer.html https://www.vagrantup.com/ https://www.packer.io/ （docker 也算是這種風格『復興』的重要推手） PS. 除了做 immutable server，vagrant 輔助開發就已經很方便了。 我在專案下都附 1 個 vagrant 管理的 vbox 並設好 private ip jdbc 在 dev 階段的 config 都是連自己的 vagrant box 內的 mysql 在部署階段由 deploy tool 上正式 server 的設定 [OSDC 2013][20130420 1120~1150][第一會議室] ihower - A brief introduction to Vagrant https://www.youtube.com/watch?v=5hyxqeG_mt8 導入 Vagrant 做開發配置 https://ingramchen.io/blog/2014/06/vagrant-up.html =============================================================== (工商服務?!) (不過我沒收錢，也沒有人會付錢給我，只是剛好知道曾有這些課程) ITHOME 就協辦相關 workshop，讓社群、業界講師開課： 1. Ansible 自動化組態管理實戰講堂 2. Chef 自動化組態管理實戰講堂 另外可以留意，只要有任何免費、付費資源通常會來這宣傳 https://www.facebook.com/groups/DevOpsTaiwan/?fref=ts --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.227.38.73 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1459614489.A.583.html ※ 編輯: qrtt1 (36.227.38.73), 04/03/2016 00:30:39 ※ 編輯: qrtt1 (36.227.38.73), 04/03/2016 00:55:29 ※ 編輯: qrtt1 (36.227.38.73), 04/03/2016 21:42:45