本系列文資料可參考以下：

• Github
• Gitbook
• Mr.沙先生

身為一個 Operations 出身的工程師，過去幾年我一直認為自己是 IT 界的黑手，Ops 對於企業來說是一個不可或缺的職位，要上線、要佈署總是要等待大家都下班後才能默默的執行，凡事跟科技有關係的東西不懂就先問 Ops，有插電的就是你的啦！！

資訊業黑手之路

對於企業老闆來說這個職位無法替公司帶來利益，可是裁掉的話公司又無法營運，當網站活的好好的這絕對是應該的 (慣老闆：你沒動他為什麼會壞？)，然而出問題的時候 Ops 總是要第一線 On Call 站出來 Debug，如果沒修好就不是只有手黑而已，連臉都黑了，這時候又會出現 "慣老闆：那個某某某為什麼網站又不能動了。"、"Developer：我昨天上線的時候不是好好的嗎？我在我的電腦測試 OK 的阿！"，然後就默默又揹了黑鍋，多數身為 Ops 職位的工程師或多或少都會感受到這樣的感覺。

然而 Ops 重複性質的工作項目隨著科技規模龐大也開始越來越多，每有新專案地基都大同小異，在這樣的性質下做了三年，開始對於人生有了警訊，在這樣下去終究只是個黑手。

從一開始嘗試自己用 script 來把這些事情重複性質的工作做完，終於開始享受到有時間可以去讀一些除了 Ops 以外的東西 (i.e Database、Infosec、Coding)，但是隨著專案越來越龐大，這些 script 也越來越複雜，隨著維護工作越來越艱難，跟開發團隊的鴻溝也越來越深，開始陷入工作的瓶頸中。

DevOps 文化的覺醒

那時我剛進入現在的公司並且當時正開始推行 DevOps 文化，在 DevOps 文化建立初期非常艱難，企業既有的人文與文化非常重要，在一間很有年資的企業無法喊喊口號就能開始 DevOps，但這時我非常慶幸是一位 Ops，因為身為一位 Ops 你很容易跟 Developer、DBA、InfoSec .. 等等團隊進行 co work，從這樣的部門角色很容易可以把觸手伸到(誤)到各單位，推廣 DevOps 是一件很有效的方式 (當然也需要權力及制度的推力)

從導入 DevOps 文化中我開始了解到，推行 DevOps 最直接的方式就是把 Dev 和 Ops 的工作都攪在一起，擁有相同的思維、共通的目標就不會讓鴻溝加深，最直接的方式就是 CI / CD 與 自動化，但是身為 DevOps 的推廣者怎麼可以空口說白話呢，一定要有一些具體的事蹟才能說服其他人，所以在 2017 年初我開始接觸了 Puppet，要做就先從解決自己的問題開始 ...

目錄

• Day 1 - 前言
• Day 2 - Puppet 是什麼？能吃嗎？
• Day 3 - Puppet 的架構
• Day 4 - 你不能不知道的 Puppet 小常識
• Day 5 - Master-Agent 架構 - Master 安裝
• Day 6 - Master-Agent 架構 - Agent 安裝
• Day 7 - Master 和 Agent 之間的關係
• Day 8 - 手把手系列 - 第一個 manifests
• Day 9 - 手把手系列 - 第一個 module
• Day 10 - modules 的篩選
• Day 11 - 處理 Resource 之間的順序
• Day 12 - 手把手系列 - 常用的 Resource
• Day 13 - 用 Hiera 來處理資料
• Day 14 - 用 eyaml-hiera 來處理機敏資料
• Day 15 - Puppet 內建的檔案系統
• Day 16 - 手把手系列 - 用 templates 來處理檔案內容
• Day 17 - 什麼軟體盤點？就用 facter 就好啦！
• Day 18 - 手把手系列 - Linux 實戰
• Day 19 - 手把手系列 - LAMP 實戰
• Day 20 - 手把手系列 - Nginx + NodeJS 實戰
• Day 21 - 和很潮的工具結合 - Docker
• Day 22 - 和很潮的工具結合 - Packer
• Day 23 - 和很潮的工具結合 - Vagrant
• Day 24 - 設計基於 cronjob 的分散式概念
• Day 25 - 設計 Role and Profile 架構的 Puppet
• Day 26 - 讓 Puppet 進版控吧！
• Day 27 - Puppet 的測試工具
• Day 28 - 備份與還原
• Day 29 - 疑難雜症 Q&A
• Day 30 - 總結

致謝

非常感謝團長 Miles 的邀請，以及隊員 聖佑 的互相努力，在這互相傷害的 30 天同甘共苦。