凍仁在學時很喜愛《Unix 與 Linux 自動化管理》一書，並幻想著有朝一日也能達到自動化管理的境界。但對於 IT 維運者而言，有時間寫筆記就很難了，更別說是把安裝 (Setup)、部署 (Deploy)、安全性更新 (Security Upgrade) 等步驟寫成可以自動化的 Script！
凍仁從 2015 年末時開始接觸 Ansible，才知道有這麼個比 Shell Script 和 Python 還好用的組態管理工具 (Configuration management Tool) 1，相信透過 Ansible 的幫助一定可以讓我們大家都提早下班的！(笑)
本次將沿用凍仁先前的簡報，並藉由圖文並茂的方式彌補簡報不足的地方。
對於凍仁而言，現代的 IT 人得具備十八般武藝，從系統規劃、部署 (Deployment)、開發 (Development)、測試 (QA)、維運 (Operations)、監控 (Monitoring) 到效能優化 (Performance Optimisation) 等樣樣都要融匯貫通。
在現代，有個叫「DevOps」的名詞概括了不少技能和工具，如 Ansible, Chef, Docker container, Git, Jenkins CI, Vagrant, Zabbix monitoring server … 等，凍仁在此就不多述。(若想深入了解 DevOps 是什麼？2 歡迎加入 DevOps Taiwan 社團)
簡而言之，現在的資訊人員 (IT Engineer) 除了要會管機器、管網路、on-call 之外，還得要會寫些自動化的工具來輔助自己，不然是難以在下一個世代生存的！
不管是從 Ops 跨到 Dev，還是從 Dev 跨到 Ops，到頭來都是一樣，就看哪邊投的技能點數比較多！
以下是凍仁很喜歡對照表，多年前的凍仁常常耗費不少的時間在安裝作業系統、架設公司業務所需的大大小小服務、寫寫工作日記提醒自己改了什麼設定；如今凍仁會藉由虛擬化技術、雲端運算和組態管理工具等，在相對快速的時間裡完成任務。
寫筆記不如寫工具！更何況還是可重複使用的工具！！
在提好處之前，先來說說凍仁接觸「自動化組態技巧」後的壞處有哪些？
- 學了一套組態工具後就會想用它一統天下！
- 原先以為學好 Ansible 以後，就可以不用繼續看官方文件，但事實正好相反。(笑)
- 會不斷的想把重複的工作自動化，然後丟上 GitHub 和 Ansible Galaxy！
文中提到的組態，其實是從 Configuration management 翻譯過來的。
導入自動化組態工具，除了可以減少重複性的工作外，最重要的可以提升正式環境 (Production) 的穩定性和可靠性！
圖片來源：Ansible as Automation Glue
當每次的版本釋出 (release)、部署 (deployment) 都會出現不可預測的問題時，將會冒出許多例外工作，這將會大幅度拖累我們的工作進度。
養兵千日用在一時，當我們準備好，就可以在很短的時間內對正式環境進行部署和維護等變更工作，尤其是半夜 12 才要上線的那種 ...。
還記得那一年，開發者 (Developers) 透過 FTP 手動更新程式，發現臭蟲 (bug) 想退版卻無從下手的慘痛經驗！這不只拖累公司整體的業務，還引起了顧客的不滿。
但其實我們只需透過自動化組態工具管理這些變更，再搭配版本控制系統和測試，就能有效避免這類問題發生。
準備好了嗎？Ansible 的大門就在前面了！
Footnotes
-
組態管理工具 (Configuration management Tool) 一般我們會簡稱為 CM Tool，而在業界我們還會用 Infrastructure as Code (IaC) 的字眼來形容這些工具。 ↩
-
隔壁棚的 Miles 有專門撰寫篇什麼是 DevOps？的文章，不妨也參考一下喔。 ↩