這個站在放什麼

Fri, 02 Oct 2026 00:00:00 GMT

這是 ivan note 的第一篇文章，順便把這個站的規則寫下來。

三種內容

站上的內容分成三種，各自有固定的位置：

腳本是特別的一種：它的頁面不是我另外寫的，而是它自己資料夾裡的 README.md，一個位元組都不改。文章和工具則是專門為這個站寫的，開頭有一段 frontmatter 記錄標題、日期和標籤。

一篇文章可以標明它在講哪些工具、哪些腳本，那些頁面就會反過來列出「提到它的文章」。標籤則跨三種內容通用，點開 kubernetes 會同時看到相關的文章、工具和腳本。

在 posts/ 放一個 markdown 檔，開頭寫：

yaml

---
title: 標題
date: 2026-10-02
summary: 一兩句話，會出現在列表與搜尋結果裡。
tags: [kubernetes, linux]
---

push 之後網站會自動重新產生。

Fri, 02 Oct 2026 00:00:00 GMT

自動化腳本最常見的死法不是寫錯邏輯，而是文件與腳本各自漂移：README 上的參數腳本早就改掉了，複製貼上的指令指向已經改名的 repo。

我的做法是用三個約束把漂移擋住。

網站上每一個腳本頁，都是對應資料夾 README.md 的逐位元組渲染，不另外維護一份文案。文件與腳本永遠出自同一個 commit，不可能有「文件寫的是舊版」這種事。

會動到主機狀態的腳本一律支援 --help 與 --dry-run。先看它要做什麼，再決定要不要真的做。

例如 Proxmox VE ISO 軟連結同步，第一次跑之前先預演：

bashsudodry-run

curl -fsSL https://raw.githubusercontent.com/CTJ425/script-docs/main/script/pve_link_iso/pve_link_iso.sh | sudo bash -s -- --dry-run

shell 語法與 ShellCheck、Docker Compose 設定、以及文件裡每一條 raw.githubusercontent.com 指令是否仍能解析，都在 CI 逐條驗證。貼出去的指令壞掉時，是我先知道，而不是複製它的人。

NOTE

這三件事保證的是「指令存在、語法正確、設定能解析」，不保證它在你的機器上一定能跑通。所以才有 --dry-run。