※ 引述《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