※ 引述《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大先前的文章推測你們開發人員的平均實力遠遠超過我們，
要是再考慮到你們使用比較好的開發工具，建置環境的手冊又比較同步的話，
我相信你們建置開發環境的速度一定很快，但我們就未必了....