#iac

instance 專屬設定 應用與它的設定 烘烤線 agent・共用設定 套件與 runtime 基底 OS 線以上:開機時才灌(fry) 彈性、改了馬上生效; 但開機慢、開機時可能失敗 線以下:烤進 image(bake) 每台一模一樣、開機即用; 但改一行要重建 image 線可以移:往上移=開機快、變更慢;往下移=變更快、開機慢——沒有免費的方向

Servers as Code:烘烤線畫在哪,決定你開機多快、改動多痛

· tech · 約 5 分鐘 · 📚 Infrastructure as Code 讀書筆記 #8

Stack 那層管的是「有哪些資源」;這篇往下鑽進資源裡最有內容物的那種——伺服器本身。一台 server 從開機到能服務,身上堆了一整疊東西,而 IaC 在這層要回答兩個問題:這疊東西什麼時候放上去…

#iac#devops#book-notes

複製貼上 一包全裝 可重用 stack code A code A' code A'' dev staging prod ✗ 三份 code 各自漂移 改三次,忘一次就失真 一份 code 同一個 stack(同一份 state) dev stg prod ✗ 環境共用爆炸半徑 改 dev 的失誤可能炸到 prod 一份定義 dev staging prod 各自的 state,差異只在參數檔 ✓ 測過的那份定義 就是上線的那份

Stack 與環境:staging 不該是另一份 code,是同一份的另一個 instance

· tech · 約 5 分鐘 · 📚 Infrastructure as Code 讀書筆記 #7

進入書的第二部分:stack。前面講切割時一直在說「一個 stack」怎樣怎樣,這篇先把這個詞站穩,再處理它最日常的應用場景——同一包基礎設施,要生出 dev、staging、prod 好幾份。這件事…

#iac#devops#book-notes

單體:爆炸半徑 = 全部 小元件:爆炸半徑 = 一塊 網路 資料庫 服務 A ← 改這 服務 B 監控 權限 改一行,整包一起 plan、一起冒險 網路 stack 資料 stack 服務 A ← 改這 服務 B 只 plan、只動這一塊;其他透過介面往來

小而簡單的元件:爆炸半徑決定你敢不敢改

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #6

三個核心實踐的最後一個。上一篇說變更批次要小,這篇補上它的前提:批次小得起來,元件先要小——如果整個系統是一包巨大的 stack,再小的改動也會被迫帶著整包一起上路。這章講的就是怎麼把基礎設施切成「小…

#iac#devops#book-notes

端到端・整合 起一個真的測試 stack 單元測試・plan 預覽 靜態分析:lint・validate・policy as code 回饋:秒 → 分 → 十分鐘

持續測試與交付:品質來自快回饋,不是守關卡

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #5

三個核心實踐的第二個。上一篇把一切變成程式碼之後,下一個問題自然是:程式碼會錯,怎麼知道這次變更是安全的?書的答案跟傳統直覺相反——不是在上線前設一道更嚴的關卡,而是把驗證拆碎、塞進工作的每一步。品質…

#iac#devops#book-notes

定義檔(想要的終點) web 伺服器 × 3 現況 web 伺服器 × 2 比對(plan) 差異:+1 台 執行(apply) 只補差異的部分 把現況推向定義 跑第二次?比對差異 = 0 → 什麼都不做。這就是冪等

一切皆程式碼:宣告式寫終點,程序式寫路徑

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #4

前三章鋪完為什麼、原則、平台,從這章開始進入三個核心實踐,第一個就是招牌:把所有東西定義成程式碼——不只伺服器,網路、pipeline、監控、權限,全部。好處書裡列得很整齊(可重用、一致、透明、可測試…

#iac#devops#book-notes

應用層 你的產品與服務 應用執行環境 Kubernetes、PaaS、資料庫叢集 基礎設施平台 運算 VM · 容器 · FaaS 儲存 block · object · DB 網路 VPC · LB · DNS 可程式化(API) 隨需(分鐘級) 自助(不用開票)

基礎設施平台:你家的雲,是真的雲嗎?

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #3

前兩章講完 為什麼和原則,第三章回頭補一個地基問題:IaC 要有東西可以 code——你的定義檔寫得再漂亮,也要有一個收到 API 呼叫就能生出資源的平台在下面接著。這章就在講這個「動態基礎設施平台」…

#iac#devops#book-notes

前提:任何元件隨時會壞(便宜的 commodity 硬體) 流程可重複 + 變異最小化 一切可重現 從定義檔重建任何東西 一切可拋棄 牛,不是寵物 故障=例行重建 不再是災難 可靠性從「硬體不會壞」搬到「軟體重建得快」 鏈條由左往右:上游做不到,下游全是空談

雲時代基礎設施的原則:壞了就重建,可靠性來自軟體

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #2

第一章說雲時代該擁抱變更,這章回答「憑什麼敢」。前提先翻轉:鐵器時代的可靠性是用錢買硬體——更貴的機器、雙電源、RAID、原廠保固;雲跑在海量便宜的 commodity 硬體上,供應商直白告訴你:任何…

#iac#devops#book-notes

鐵器時代 · Iron Age 雲時代 · Cloud Age 實體硬體:變更以週、月計 最佳化方向:減少變更 重審批、重文件、凍結窗口 軟體定義:變更是 API 呼叫 最佳化方向:擁抱變更 自動化 + 快速回饋顧品質 錯不起 → 少改 改得快又安全 → 常改、用變更學習

Infrastructure as Code 是什麼?從「變更」的成本翻轉講起

· tech · 約 7 分鐘 · 📚 Infrastructure as Code 讀書筆記 #1

開一個新系列:讀 Kief Morris 的 Infrastructure as Code,用的是第三版(2025)——副標從第二版的 Dynamic Systems for the Cloud Ag…

#iac#devops#book-notes