Blogs

前言 我的 Homelab 跑著一台 Proxmox VE，底下有一個 Ubuntu Server 24.04 的 VM 負責跑 k3s cluster，這個 cluster 接管了家裡所有的自架服務：從 Vaultwarden 密碼管理、Karakeep 書籤、Filebrowser 文件管理，到 Wakapi 開發時間追蹤，大大小小跑了十幾個服務。 這個架構一直跑得很穩。直到 Linux kernel 7.0 發布，我才開始動搖。 kernel 7.0 的各種新特性讓我心癢，Ubuntu 26.04 LTS 剛好以 kernel 7.0 作為預設核心，理論上從 24.04 升上去就能一步到位。但在一個跑著十幾個服務的生產 VM 上執行 do-release-upgrade，那種心臟發抖的感覺，即便有做好備份，還是讓我遲遲下不了手。 就在猶豫要不要升級的當下，我問了自己一個問題：「我要繼續用 Ubuntu 嗎？」 這個問題打開了一扇門。我的 Linux desktop 是 openSUSE Tumbleweed + KDE Plasma，用了三年、換過兩台裝置（筆電和桌電），沒有遇到太多問題。Tumbleweed 的滾動更新讓我一直跑著最新的 kernel，升級這件事從來不是一個需要另外排行程的壓力事件。 既然 desktop 側已經對 openSUSE 生態有信心，server 側為什麼不試試看？ 這讓我開始認真考慮：有沒有一種 OS，讓 server 的升級這件事也變成「預設安全」而不是「需要勇氣」？ 為什麼選 OpenSUSE MicroOS OpenSUSE MicroOS 是一個 Immutable OS（不可變作業系統），核心特性有幾個： ...

前言 在大型系統或需要長期維護的產品中，導入 DDD（Domain-Driven Design）或 Clean Architecture 幾乎是業界的標準答案，分層清晰、職責明確、可測試性高，這些優點毋庸置疑。 但問題是，不是每個專案都是大型系統。 當你面對的是一個內部工具、side project、或是剛起步的新產品，Clean Architecture 的大全套 Use Case、Port、Adapter、Aggregate、Repository Interface 全放 domain，往往會讓你在還沒寫第一行商業邏輯之前，就先在資料夾結構裡迷路了三個小時，或是讓不熟悉的貢獻者花費大量時間在閱讀架構。 這篇文章想討論的是：在不犧牲可測試性與可維護性的前提下，哪些抽象可以捨棄、哪些值得保留，以及我自己踩過的一些坑。 捨棄什麼 獨立的 Port/Adapter 層 Clean Architecture 中，Use Case 透過明確定義的 input/output port 與外界溝通，搭配 Adapter 負責格式轉換。這在大型系統中確實有其價值，但它帶來的代價是：為了讓每一層都能獨立替換，你需要維護大量的介面與轉換邏輯，而這些轉換邏輯往往只是把 A struct 的欄位複製到 B struct。 在小專案中，這條轉換鏈可以大幅縮短。HTTP handler 本身就可以負責 DTO 的轉換，不需要再多一層 Adapter。 DDD 的 Aggregate Aggregate 是 DDD 中保護業務不變式（invariant）的邊界，透過 Aggregate Root 統一管理相關物件的存取。這個概念本身沒有問題，但在小專案中，如果業務規則還不夠複雜到需要嚴格的不變式保護，過早引入 Aggregate 反而會讓簡單的 CRUD 操作變得冗長。 保留什麼 捨棄了部分複雜度之後，剩下的四層架構已經足以應付絕大多數的小專案需求。 package domain 這裡只放 Domain Model 與 Value Object。 值得特別說明 Domain Model 的定義。它不等同於 DDD 裡的 Domain，不是什麼深奧的設計概念，Domain Model 只是在描述「這個應用程式如何跟外部世界互動、邊界在哪」，也就是你的核心資料結構與它們身上的行為。有些「賣課」的人喜歡把 Domain Model 直接等同於 DDD 的 Domain，實際上它是個更基礎、更普遍的概念，可以參考這支影片的解釋。Domain Model 中不需要也不該出現任何技術細節，例如回傳是否是 JSON 等等，這些 Domain Model 甚至要能讓 PM 與非技術人員也「聽的懂」。 ...

TL;DR 馬上就看到有小王八蛋想壞壞 前言 2025 年 11 月，Kubernetes SIG Network 發布了一篇公告：ingress-nginx 將正式退役。 這個消息讓不少人震驚，但嚴格來說有個細節需要釐清。目前市場上有兩個長得很像的 nginx ingress controller： kubernetes/ingress-nginx：由 Kubernetes SIG Network 維護，這次宣布 EOL 的就是它。 nginx/kubernetes-ingress（又稱 NKS）：由 F5 / NGINX Inc. 維護，目前仍持續開發中。 我的 homelab k3s cluster 一直以來用的是 F5 維護的版本，嚴格來說不在這次 EOL 的範圍內。但這個公告還是給了我一個動力，與其繼續追蹤兩個版本之間的差異、擔心哪天又有什麼變化，不如趁這個機會把遷移一次做完。 遷移目標選定 Traefik v3，原因有兩個： k3s 內建 Traefik 作為預設 Ingress Controller，1.32 版本後升級為 Traefik v3，搭配 HelmChartConfig 管理，和 cluster 的整合度最高。 順手引入 CrowdSec 主動防護——長期以來我的服務靠著 Cloudflare proxy 當唯一守門人，但我一直想要在 Ingress 層就能即時判斷並封鎖攻擊者 IP，而不只是依賴前端的 CDN 過濾。 為什麼不選 Cilium Gateway API 在決定遷移到 Traefik 之前，我也閱讀了 Gene 的告別 ingress-nginx：Cilium Gateway API 遷移筆記，評估過 Cilium Gateway API 方案。Cilium 在 CNI 層整合了 Gateway API，理論上能提供更底層、效能更好的流量控制，且完全符合 Kubernetes Gateway API 的標準規範。 ...

前言 如果你有認真對待自己的資料，應該聽過 3-2-1 備份原則： 3 份備份 2 種不同的儲存媒介 1 份異地備援 前兩項在家中的 Homelab 環境相對容易做到，但「異地」這個字往往是大多數人的盲點。硬碟壞掉？用 Proxmox Backup Server (PBS) 還原。系統崩潰？從 PBS 拉一份回來。但若是家裡發生火災、淹水，或是更平凡的情況——你不小心把整台 Proxmox VE 的 NVMe 連資料一起刪掉——這時候同一個屋簷下的所有備份都會跟著陪葬。 我的 Homelab 環境是一台 Proxmox VE 搭配一台 Proxmox Backup Server，跑著包含 k3s、Vaultwarden 等各種服務。在研究了很久的異地備援方案後，我決定在歐洲架設一台 PBS，讓它透過 WireGuard 隧道主動把家裡的備份「拉」過去，讓 321 中的那個「1」真正落地。 這篇文章會記錄完整的架構決策過程，從為什麼選 Hetzner、選哪個方案、到實際的設定步驟，以及中間踩過的坑。 為什麼選 Hetzner Hetzner 是一間位於德國的基礎設施供應商，在評估異地備援的雲端供應商時，我的優先考量是：便宜、隱私安全、技術友善。 GCP / AWS 的問題 第一個念頭當然是最熟悉的 GCP 或 AWS，畢竟都是主流雲端。但把兩者丟進計算機後，答案很快就出來了： 以我「最終」需要的規格： 2 vCPU / 4GB RAM VM 80GB 高速 Storage 用於 PBS 備份 500GB 慢速 Storage 用於 NAS 備份 方案 預估月費 Hetzner- CX23- 80GB Volume- BX11 Storage Box 約 $15.73 USD AWS 同級配置- t3.medium- gp3 80GB- S3 500GB 約 $50 USD GCP 同級配置 相近 光是這個差距就已經結案了。AWS 和 GCP 的小型運算實例本身就已經比 Hetzner 貴好幾倍，Block Storage 的單價更是幾乎翻倍，再加上對外流量費用（下載資料還要另外收），災難復原時光是把 500GB 拉回來就可能要多付幾十美元。 ...

Web 仔要有 Web 仔的自覺 前言 前陣子收到了 Murphy 的需求，嘗試使用 Tauri 寫了一個桌面 App。Tauri 結合 Rust 與 React 的體驗相當不錯，打包出來的體積也十分理想。 但身為一個主要撰寫 Golang 的後端工程師，內心總有一個聲音：「如果能用 Go 來寫桌面應用，那該有多好？」 眾所周知，Golang 在原生的 Desktop GUI 框架上一直沒有特別強勢的殺手級專案（過去使用 Fyne 的經驗不算太好）。在環顧了一眾基於 Chromium 的 Electron 或是基於系統 WebView 的 Tauri 後，決定走一條稍微不一樣的「老路」：使用 Wails 搭配 HTMX 與 Templ。 最終的產物就是 Dub 一個跨平台的批次檔案重新命名工具。更甚，在 Linux 上打包出來的可執行檔只有約 3MB，並且完美支援 macOS 與 Linux，且幾乎沒有複雜的前端狀態管理負擔。 為什麼是 Wails + HTMX？ 在選擇桌面應用程式的技術方案時，我們通常有幾個考量 Electron: 開發體驗極佳，生態系最豐富，但代價是動輒上百 MB 的體積與高昂的記憶體佔用。對於一個小工具來說，太過沉重。（這也是我優先選擇 Zed.dev 作為主要編輯器的原因） Tauri: 效能極佳，體積小，但後端需要寫 Rust。雖然 Rust 很香，但有時候只想用最熟悉的 Go 快速把邏輯刻出來。 Wails: 與 Tauri 類似，採用前端網頁技術結合系統原生 WebView，但後端語言是 Golang。 既然選了 Wails，前端該用什麼？ 現代前端框架（React, Vue, Svelte）通常需要建置複雜的 SPA（Single Page Application），並透過 JSON API 與後端溝通。但對於一個狀態並不複雜的工具軟體，不想在前端再維護一份狀態。 ...

在 2025 Recap 的展望中寫下了「與 +1 首次踏足國外」，沒想到兌現的速度比預期快得多，2026 年的第二天，我跟 Murphy 就站在了關西國際機場。 會選擇日本關西作為首次出國的目的地，原因很單純：我們都各自來過，作為初次日本自由行，熟悉的地方還是比較安心。加上 2025 年 10 月才從五十音開始學日文，正好拿這趟旅程來驗收 N87 的日文實力（？ 五天的行程，從京都走到大阪，從零度的細雪走到通天閣的暖陽。這篇拖了快兩個月才動筆的遊記，就當作是對這趟旅程的交代吧。 Day 1（1/2）：初雪與初売り 搭乘星宇航空 JX820 班次，Airbux A330-900neo 機型，這次旅行選擇星宇也是為了體驗 Airbus 的飛機。11:10 分落地後，11:20 分就開始排隊出關（這邊禁止拍照），11:40 順利出關拿完行李！原本預計出關會要約莫一個半小時，訂了 12:44 分的 JR Haruka 由於關西國際機場極高的效率讓我們在機場空等了一小時 XD。 由於吃了暈機藥，在 Haruka 時仍持續處於昏迷狀態，抵達京都時已經下午兩點，隨即轉乘烏丸線到烏丸御池站，出站走了一小段路就到了這兩晚的住所，Hotel Resol Trinity Kyoto（京都RESOL TRINITY酒店）。 我與 Murphy 在這次旅行的分工是，我負責京都部份，Murphy 負責大阪部份，而京都的住宿，我只花了半小時搜尋「京都 住宿 ptt」就搞定了，我並沒有過多研究 Hotel Resol 整體的歷史等等，單純是因為飯店的窗戶有一個紙門設計，我就被迷惑了。好在運氣始終不錯，當從京都的大馬路上轉進小巷子，一間外裝不太起眼的飯店映入眼前，進入飯店後裝潢與外裝截然不同，雖然知道他是ホテル但濃濃的りょかん味，特別是一樓還有大浴場，這兩天我都在這邊洗澡，所以並沒有感受到評價所說的「浴室很小」的感覺。由於是新年期間，附近的學校也跟著放假，大廳還提供了原先供應給學校的鮮乳，屬實幸運。 下榻的飯店距離錦市場只有十分鐘的步行距離，放完行李後，緊接著步行前往藤井大丸，體驗日本新年的「初売り」，此時室外的溫度零度，天空飄下了細雪，即便十分興奮，還是會擔心外套濕掉。我高估了我耐寒的能力，只穿了短袖、中層與棉質的薄外套就來了這零度的京都，Murphy 在大丸買了件新的羽絨外套後，我就把他身上的搶過來穿，撐過了這幾天。買完戰利品後先回到飯店放下，畢竟我們接下來還有行程，這就是飯店距離商圈近的好處。 ...

為什麼在這個時間點讀這本書 最近對於如何在 LLM 時代帶領團隊一起提昇生產力感到困惑。當 AI 能在幾秒鐘內生成幾百行程式碼，「寫程式」這件事的門檻似乎降到了前所未有的低點。但門檻低了，品質呢？ 當「每個人」都在養龍蝦，有了生產力焦慮，TypeScript 寫的 OpenClaw 才剛出現，Python 的 NanoBot 馬上跟上，接著是 Golang 的 picoclaw，然後 Rust 的 ZeroClaw 也來了。 根據 ZeroClaw 做的 benchmark，這些 Agent 已經降到小於 5MB 的記憶體佔用與 10ms 的啟動時間，「種族」為人類的我們對於產出軟體來說還剩什麼？ 帶著這個問題，我決定先從自身出發，找出在 LLM 時代還能保持軟體工程「工匠精神」的誘因。於是翻開了 Robert C. Martin 的 Clean Craftsmanship。 這本書分為三個部份：紀律、標準、道德。一半以上的篇幅在講述 TDD 這個老生常談的開發方式，但透過 TDD，我們更能知道何謂軟體的「品質」。以下是我特別書籤的幾個段落。 紀律 童子軍規則 離開營地時，要比你來時更乾淨。 這也是在 Clean Code 一書就提到的概念。每次微小的重構，都能小程度的減少技術債的產生。不需要一次大刀闊斧，只要每次經過一段程式碼時，順手讓它變得更好一點。 讓我想到 Claude is not a senior engineer (yet) 這篇文章中提到的 Sweeks——一位被稱為「園丁」的 distinguished engineer，他不斷地重寫、收緊抽象，讓經過他手的程式碼都變得更乾淨。我們都想成為 Sweeks，對吧？ 在 LLM 時代，AI 擅長的是「組裝」現有解決方案，但它缺乏 Sweeks 那種「看到可以更好的地方就會忍不住動手」的靈魂。童子軍規則提醒我們：這份靈魂不能丟。 Test Doubles 的正名 書中透過實戰的例子講述了所有 test double：Dummy、Stub、Spy、Mock、Fake。 坦白說，我曾經在諸多 repo 中看到這些名詞卻沒有實際使用它們。頂多在 DI 時製作了一個「用於模擬 database repository 的 implement」，或是使用了 gomock 這種套件來產生 mock，然後把所有替身都統稱為 mock。 ...

前言 在我們目前的應用程式架構中，由於高度與 Kubernetes 耦合，服務啟動與運作期間需要頻繁地去讀取 K8s 中的 ConfigMap。為了達成配置熱更新（Hot Reload），我們引入了 Kubernetes client-go 中的 informers 機制來監聽 ConfigMap 的 CRUD 事件。 雖然 K8s 官方提供了 fake client 讓我們能測試 informers 的邏輯，但在 Service Code 的層級，我們往往需要封裝一層更適合業務邏輯的 ConfigWatcher。Golang 引以為傲的輕量級 Goroutine 與 Channel 搭配非常適合用來處理這種非同步的事件傳遞。 然而，一旦涉及到 Goroutine 的非同步測試，「時間」往往就成了最大的敵人。 遇到的問題：不穩定的測試與魔法數字 為了模擬 ConfigMap 的變更通知，我們定義了一個 ConfigMapWatcher 介面與對應的 Event 結構： const ( ConfigMapUpdateEventTypeAdded ConfigMapUpdateEventType = iota ConfigMapUpdateEventTypeModified ConfigMapUpdateEventTypeDeleted ) type ConfigMapUpdateEvent struct { Name string Type ConfigMapUpdateEventType Value map[string]string } type ConfigMapWatcher interface { Watch(ctx context.Context, eventCh chan<- ConfigMapUpdateEvent) error } 接著，我們很自然地在 testing 中實作了一個 fake 物件來模擬事件發送： type fakeConfigMapWatcher struct { injectCh chan ConfigMapUpdateEvent watchErr error watchOnce sync.Once } func newFakeConfigMapWatcher() *fakeConfigMapWatcher { return &fakeConfigMapWatcher{ injectCh: make(chan ConfigMapUpdateEvent), } } func (f *fakeConfigMapWatcher) sendEvent(event ConfigMapUpdateEvent) { f.injectCh <- event } func (f *fakeConfigMapWatcher) Watch(ctx context.Context, eventCh chan<- ConfigMapUpdateEvent) error { if f.watchErr != nil { return f.watchErr } f.watchOnce.Do(func() { go func() { for { select { case <-ctx.Done(): return case e := <-f.injectCh: eventCh <- e } } }() }) return nil } 問題來了，當我們在寫單元測試時，呼叫 sendEvent 將事件送入 channel 後，消費者端（也就是我們的業務邏輯 Goroutine）並不會「立刻」收到並處理完成。為了確保 assert 斷言執行時，業務邏輯已經跑完了，我們被迫在測試中加入 time.Sleep： ...

前言 自從 RouterOS 在 v7.13 引入 container 功能後，這為我們這些 Homelab 愛好者開啟了一扇新的大門。我們終於可以在路由器上原生執行 container，這意味著一些網路相關的基礎設施服務（Infrastructure Services）可以從原本的伺服器中遷移出來。 以我為例，過去我的 Adguard Home 是 deploy 在我的 Homelab 伺服器群中。然而，作為一個喜歡「折騰」的工程師，Homelab 難免會因為硬體更換、系統升級或是實驗新架構而需要重啟。每當這時候，家裡的網路 DNS 解析就會中斷，隨之而來的就是家人的抱怨。 為了解決這個單點故障（SPOF）的問題，我決定將 Adguard Home 改為 deploy 在 Router (RB5009UG) 上。這樣做不僅減少了物理上的 latency，更重要的是將「網路服務」與「應用服務」解耦，避免因為 Homelab 的維護而導致全家斷網。 這是遷移後的狀態： [user@RB5009UG] > container print Flags: R - RUNNING Columns: NAME, ROOT-DIR, INTERFACE, MOUNTLISTS, ENTRYPOINT # NAME ROOT-DIR INTERFACE MOUNTLISTS ENTRYPOINT 0 R b51e0424-8fce-4c3d-b4bb-6493f76aa24b /usb1/container/adguardhome adguardhome adguardhomeConfig /opt/adguardhome/AdGuardHome RouterOS v7.21 的新變革：App 而在最近發布的 RouterOS v7.21 中，Mikrotik 給我們帶來了更方便的 container 部署方式，他們稱呼為 App。 ...

最近在檢視公司內部的專案時，針對其中一個 container image 進行了優化。在一個簡單的 commit 後，我們的 image size 從 1.82GB 修正到了 1.18GB。 透過 dive 查看，Image Efficiency 更是從不及格的 69% 飆升到了 99%。 這讓我回想起過去寫 Dockerfile 時，常常因為不了解 Docker Layer 的機制，或是為了寫起來「方便」，而踩到了許多效能與安全的地雷。 致命的 chown 這次優化的核心，其實源自於一個非常常見的操作：修改檔案權限。 在我們的案例中，Dockerfile 原本是這樣寫的： # Bad Practice: recursive chown after copy FROM ubuntu:22.04 WORKDIR /app COPY . . # ... install dependencies ... RUN dpkg -i packages/*.deb # Change ownership for security reasons RUN groupadd -r appuser && useradd -r -g appuser appuser RUN chown -R appuser:appuser /app 看起來邏輯很正確：把檔案複製進去，安裝套件，最後為了安全性將檔案權限交給非 root 使用者。 ...