※ 引述《qrtt1 (有些事，有時候。。。)》之銘言： 謝啦~ q大 你又幫我上了一課 : ※ 引述《dream1124 (全新開始)》之銘言： : 偏好 Ruby 的由 Chef, Puppet 下手 : 偏好 Python 的由 Ansible, Salt 下手。 : (至少在選擇困難的議題上，你已省力了 50%) 難怪不常聽到 java 社群的人提這些工具，呵呵 : 依據過去你在版上的討論，加上文末提到的 Java。 : 我猜測是要部署 Java Web Application 為主， : 有點難理解這類的應用程式為何會難部署， : 你可能得再補充實際上的『痛點』才能讓有解的人給予建議 : 舉例來說： : 純 Servlet Container 像 Tomcat 有 RESTful API 能更新 : 較大一點的 Application Server 像 Weblogic 有 WLST 介面 : 能用 jython 或 ANT 來更新程式、變更設定... 其實主要希望只用少數幾樣工具就能部署各類程式到許多作業系統， 要是這工具還能夠實現你提到的 infrastructure as code 那就更好。 也就是說....我想盡可能採用統一的方法部署程式。 否則，我們還真的有 Tomcat 和 Weblogic 等環境(你是不是猜到我公司...嘿嘿) 若開發人員需要學習多套部署與管理方法才能動手開發，那也未免太麻煩。 在最近的 infrastructure as code 還沒喊得震天價響之前， 我就認為開發環境的建置方法應該要一致、自動、容易重建與複製。 現在乍看 docker 是比較可行的方案.... : : 請問大家方便解答下列的疑惑嗎？ : : 1. 如果系統的使用量不會經常變動，管理者多半不用經常調整叢集裡的伺服器配置， : : 甚至有許多系統不是叢集，這樣的話導入這類工具的效益會不會很差呢？ : 先試著回想一個問題， : 上一次『從無到有』建出完整的系統，所有機器是什麼時候的事了？ : 要建出完整的系統，從一個空的 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. 請問他們目前跟持續整合伺服器結合的狀況怎麼樣？ : 莫驚慌、莫害怕。 : 即使他們什麼外掛都沒有，還有最終一招『呼叫外部程式』 : 總可以呼叫他們的 command 去做事唄 :) 呵呵，其實這只是想盡量偷懶，我要優先評估支援範圍比較廣的工具。 : : 4. 請問有沒有人試過在開發人員行情於 42k 左右之團隊引入 Docker 建置 : : 個人的開發環境呢？ 不知道這些人能否順利上手？ 會不會遇到很特殊的問題？ : 開發人員的行情 跟 做這些事沒有關係 : 開發人員的行情 跟 做這些事沒有關係 : 開發人員的行情 跟 做這些事沒有關係 : 不管薪水多少，得要為自己謀福利。 : 包含部署應用程式的舒適感 : 與 : 維護部署應用程式的應用程式的便利性 哈..從開發人員的角度來看，像我們這樣有信心駕馭這些東西的人當然想用好工具， 但如果我真的希望能導入這些工具，那就要深入探索一些問題的答案。 因此這個問題才會看起來比較奇怪，其實我想問的是 「根據大家的經驗， 實力的行情價在42k左右的開發人員能否順利使用 docker 建置開發環境」？ 為什麼要問這個問題呢？ 或許是因為我們這裡的管理者平常根本不寫程式，不會接觸這些開發環境， 所以要是我們批評某工具很難用、妨礙工作，希望可以換掉時， 他們通常很難體會開發人員的感受，不會就這樣買單。 他們搞不好還心想「別再抱怨了，請你就是要解決這種問題的，誰工作不曾覺得難受？」 當我跟老闆提案，想介紹這些工具進團隊時， 他們會在意新進人員能否順利上手？ 如果不行的話，那公司又該投入多少資源訓練到OK？ 所謂的OK又是什麼程度？ 使用這些工具是否容易不小心損壞東西？ 導入有什麼效益？ 這些效益能否從會計的觀點量化成金錢，好讓他容易向更上級報告？ 我得先準備好上述問題的答案再跟他們討論，這樣才容易成功， 不然他們可能只會笑一笑，心想「乖喔，我知道你很認真，但別再抱怨啦~」。 因此，我覺得「要不要用」反而不是導入 docker 的核心議題....答案實在太明確了。 舉凡「開發人員能否順利上手」、「能否整合進目前的軟硬體設施」、 「解決方案是否適合公司的環境」等等問題才是該多花時間思考的。 附帶一提，我覺得這些管理者都是很認真踏實經營事業的人，只是有時候比較死腦筋。 他們分析問題的觀點其實不算很多元，常常只會管理、營運和技術的角度切入事情。 當我從人力資源的角度向他們提倡「好工具是一種員工福利」時， 他們的反應不太熱絡，我猜是不太接受這種概念，甚至根本就聽不懂。 最近我正在準備相關資訊刺激他們，希望能夠誘導他們下適當的決定。 : 即使 Docker 的 native support 已經有宣傳能在 Windows, OSX 使用 : 但要到穩定好用不確定要再等多久， : 而你的情境多是 java 為主的話，要新人快速地從無到有建立開發環境 : 在有提供手冊指引的話，沒道理一天搞不定啊 : （一定是有什麼我們所不知道的細節沒談到） 我從q大先前的文章推測你們開發人員的平均實力遠遠超過我們， 要是再考慮到你們使用比較好的開發工具，建置環境的手冊又比較同步的話， 我相信你們建置開發環境的速度一定很快，但我們就未必了.... --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.160.90.128 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1459698080.A.FF2.html 哈, 那也希望搶得到票 每一次都是忙一忙回頭看就什麼位子都沒了 可否拗板上TWJUG的高手幫忙留座位啊? XD 你們的講者太強了, 議題也很深入, 我恐怕沒什麼料好講啊~~~ ※ 編輯: dream1124 (118.160.90.128), 04/05/2016 00:20:25