🌐 This page hasn't been translated yet — showing the original Chinese. Translated posts

#devops

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

role defaults —— 最通用的預設值 group_vars —— 整個群組共用(如 prod) host_vars —— 單一機器 play vars / vars_files task vars --extra-vars(-e)永遠最大 越具體,優先權越高 群組輸給單機、檔案輸給命令列——通用預設放底層,緊急覆寫走 -e

Playbook 進階:變數、條件,與重新定義成功

· tech · 約 5 分鐘 · 📚 Ansible for DevOps 讀書筆記 #4

上一篇的 playbook 是死的:寫死的套件、寫死的路徑,只能打一種環境。第五章一口氣補上讓它活起來的所有機關——變數、條件、錯誤處理。內容很雜,但整理之後其實就三個主題:資料從哪來(變數、fact…

#ansible#devops#automation

腳本:描述步驟 「依序做這些動作」 apt-get update apt-get install -y apache2 systemctl start apache2 中斷 = 卡在半套狀態 重跑 = 每一步都可能因「做過了」而爆炸 Playbook:描述狀態 「機器最後要長這樣」 apache2 已安裝 服務 started + enabled 設定檔內容 = 模板產出 每個斷言自帶現狀檢查(冪等) 中斷 = 重跑就好;跑幾次,結果都一樣

第一份 Playbook:把 shell 腳本翻譯成宣告式

· tech · 約 4 分鐘 · 📚 Ansible for DevOps 讀書筆記 #3

上一篇說膠帶貼到第二次就該轉正——這篇就是轉正手續。Playbook 說穿了只是「把 ad-hoc 指令寫進 YAML 檔案」,但書的第四章真正想教的,是一個世界觀的切換:腳本描述步驟,playboo…

#ansible#devops#automation

逐台 SSH 登入 → 打指令 → 登出,重複三次 terminal app1 app2 db t1 t2 t3 總時間 = t1 + t2 + t3,而且手會抖 10 台就是 10 次複製貼上 Ansible ad-hoc ansible multi -a "hostname" 一行指令 inventory:[multi] 展開 app1 app2 db t1 t1 t1 平行執行,總時間 ≈ 最慢那台;預設 5 forks,-f 調整

Ansible ad-hoc:一行指令,管一群機器

· tech · 約 4 分鐘 · 📚 Ansible for DevOps 讀書筆記 #2

上一篇說 Ansible 第一天就能用——這篇就是「第一天」的實際內容。書的第二、三章其實在回答兩個很務實的問題:我要在哪裡練習?(答案:一個可以隨時砍掉重練的本機實驗場)以及還沒學 playbook…

#ansible#devops#automation

Agent 模式(Puppet / Chef) 先養 master、每台機器裝 agent Master 伺服器 節點 + agent 節點 + agent 節點 + agent agent 定期輪詢、拉取組態 開始自動化之前,先多一套要維運的系統 Agentless(Ansible) 沒有 master、沒有 agent 你的筆電 節點 節點 節點 SSH 主動推送 節點只需要 SSH + Python——本來就有

Ansible 是什麼?從告別雪花伺服器講起

· tech · 約 5 分鐘 · 📚 Ansible for DevOps 讀書筆記 #1

每個維運過伺服器的人都經歷過這個循環:SSH 登入機器、改幾個設定、裝幾個套件、登出——三個月後沒有人記得那台機器上到底改過什麼。書裡把這種機器叫做 snowflake server(雪花伺服器):每…

#ansible#devops#automation