紀錄一下從 hugo 搬家到 docusaurus 的原因

之前覺得 hugo 速度很快, docusaurus 則慢又有點小複雜
因此採用 hugo 作為我的 static site generater
但隨著越用越多功能, 開始體感到 hugo 麻煩的地方
hugo 本身依靠 layouts 來設定如何實際 rander html
通常來說就是安裝 theme
但問題會變成 theme 決定了你的網站可以用哪些功能
造就了功能會摻疵不齊, 用法各異
變成了後續維護上的麻煩
雖然剛開始看到不同 theme 覺得很棒
可實際用後發現真正算的上能用的就那幾個
然後好死不死想要的功能沒有一個 theme 完全支援
只能忍痛退讓

經過一陣時間掙扎
想想都寫 markdown 了 > 原本就是不想花時間在文書排版上
hugo 的 theme 變成又花時間在網站排版 > 變得本末導致了

所以又嘗試再看看 docusaurus

docusaurus 就沒什麼 UI 的選擇
雖然會覺得沒有個人特色, 但可以讓人更專心在內容上, 不過也許就是懶而已😆

docusaurus 實際切換後發現的優點

• link check: 會幫忙檢查是否有失連狀況, 意外挺加分
• mermaid: 支援良好 Registering icon pack 也能支援

讓我感到不舒服的是 build 速度實在太慢了
寫作時感到非常煩躁
還好官方有提供 Docusaurus Faster
雖然還是 experimental 功能, 但實測沒有什麼問題
速度是快很多, 雖然還是比 hugo 稍慢,但已經是可以接受的地步

為什麼要使用 Linux Desktop​

我相信最多人用的 desktop 是 Windows
我平常使用 Linux desktop 的原因是

1. 工作使用 Linux server
   為了讓自己更加熟悉 Linux, 因此平常也使用 Linux desktop
   另外平常需要對 Linux server 進行操作/執行 Script 等, 有同樣的 Linux 環境較方便

2. 資源較省
   對比 Windows, Linux 使用較少資源, 體感覺得 OS 執行速度快的多
   但 Linux 軟體生態較差(畢竟用的人少), 有些 Windows 上好用的 App 在 Linux 只有'🦽殘障版本'
   因此一些特定使用情境下, 效率可能反而較差

3. Windows 11 大變革
   雖然我使用 Linux desktop
   但我個人並不討厭 Windows
   不過自從 Windows 11 有許多變化
   讓我認為變得更難用了...
   因此讓我更加努力使用 Linux desktop 做為日常使用

Linux Desktop 使用歷程​

關於 Linux desktop 由於其開放性
有各式各樣的 distro, 可以在 distro watch 看到清單
因此選擇合適的 distro 就非常重要了
剛接觸 Linux 一上來馬上就是選擇障礙, 因此這邊稍微講一下心路歷程

最大的問題在於環境是否能以支撐日常使用, 以下是我認為重要的幾個點

• 硬體相容性: 總不能連用都不能用對吧？
• 軟體相容性: 勢必要有方案能夠支援日常, 比如說瀏覽器, 輸入法, 文書處理器...
• 社群大小: 因為 Linux desktop 本身就冷門, 社群大小等同於有多少人踩雷/除錯/問題解答, 使用者越多等於越穩定

以上幾點就是不斷地踩雷後找到心目中最理想 distro 的要求

在繼續前要先說明 distro 的選擇會大概分兩個方向

• Source based: 可理解為底層核心, 沒有圖形化介面
• Desktop environment: 提供圖形化介面
  除了桌面環境外, 也提供了一些 app (檔案管理/記事本/終端機...等)

Source based 我選擇 Ubuntu
我認為他提供了最佳的核心功能
以上奠定了我選擇 distro 的方向

我的 Linux desktop 使用歷程如下
Source based 就以 Ubuntu 為主
歷程都是在 Desktop environment 選擇過程
由於 Ubuntu GNOME 環境實在不討我喜歡
因此一開始從 Ubuntu flavors 來做選擇

• Xubuntu: 當時看上 Xfce,以節省資源/高速為主
  然而實際用下來發覺功能並無法滿足我的需求, 有時會當機, 進而轉向其他 Desktop environment

• Kubuntu: KDE 算一個挺主流的 Desktop environment, 實際用起來深得我心
  除了桌面系統穩定, 也有自己的龐大的 KDE app 生態, 裡面不少 App 幾乎是商業級別
  在日常使用非常加分
  然而 Kubuntu 有個挺惱人的問題, 就是 Ubuntu 的政策是以自己 patch 來維護套件, 而不是更新 source release
  而 Ubuntu LTS 的發布週期是兩年一版, 也就造成 feature 的引入要等兩年
  更何況新的 Ubuntu LTS 甚至也不會用最新版套件, 變成 feature 的引入可能要等四年
  

因此也有許多人抱怨 也有專門的文章分享如何升級 Upgrade KDE Plasma
但這樣不代表能用到最新版本, 加上穩定度堪憂, 因此又繼續尋找下個 distro
Ubuntu 官方也做出部分調整 Moves To Shipping Very Latest Upstream Kernel
然而究竟未來會如何, 我就以觀望角度看看如何發展, 不論如何, 這時間實在太久,我不想等

• Linux Mint: 算是很多人推薦的系統
  但在淺嘗 Cinnamon 環境後, 仍覺得 KDE 才能符合我需求, 因此繼續找下個 distro

• KDE Neon: 由 KDE 官方製作的 distro, 就是標榜能用最新的 KDE release
  雖然有分 Unstable/stable 但是實際用起來 stable 穩定度沒很好
  因此也常常在解決一些問題

• TUXEDO OS: 綜觀我前面需求
  找到這篇文章 Differences between TUXEDO OS, Kubuntu and KDE Neon
  簡單來說呢 TUXEDO 等於是 KDE Neon 的企業版本, 幫忙把關了 KDE 的穩定度
  至今使用體感非常好, 真的是穩定的系統

什麼是 Ubuntu​

在介紹 TUXEDO OS 之前
來說說為什麼要選擇 based on Ubuntu 的 distro

來自 Reddit 的討論

• Ubuntu LTS 給予良好的系統穩定度
• Ubuntu LTS 普遍硬體支援更好

然而也因為求穩定(feature 採用慢)+商業考量
有些人是不喜歡 Ubuntu 的
像是 Ubuntu 採用的 snap 就很多人詬病
也因此一些 distro 就是拿 Ubuntu 的好, 去 Ubuntu 的不好
變成一個 distro
opensource 很常看到的, 我 fork 你的 fork😆

什麼是 KDE​

KDE Plasma 是 Linux 社群中最受歡迎的桌面環境之一，以其極高的自由度和強大的功能著稱。以下是其核心優勢：

核心優點

1. 極致的客製化能力 (High Customizability) KDE 被譽為「桌面環境中的樂高」，幾乎每一個視覺元素都可以調整：

• 面板配置：可自由移動工作列位置、調整大小、透明度，或建立多個自定義面板。
• 小工具 (Widgets)：內建豐富工具，可在桌面直接顯示天氣、硬體監控、備忘錄或媒體控制。
• 外觀主題：內建商店可一鍵下載全球社群創作的圖示、視窗裝飾與色彩方案。

2. 優異的效能表現 (Performance) 現代的 KDE Plasma（特別是 6.x 版本）在功能與效能之間取得了極佳平衡：

• 資源佔用低：記憶體佔用通常比 GNOME 更少，甚至能流暢運行於老舊硬體。
• 反應迅速：系統動畫流暢，且允許使用者關閉特效以追求極致速度。

3. 強大的軟體生態系 (KDE Gear) KDE 擁有一系列功能極其強大的原生應用程式：

• Dolphin：被公認為 Linux 界最強大的檔案管理員，支援分頁、終端機嵌入與預覽。
• KDE Connect：殺手級應用。實現手機（Android/iOS）與電腦的深度同步，包含剪貼簿共享、檔案傳輸與遠端控制。
• Konsole：高度可自訂的終端機模擬器。

4. 適合各種工作流

• 低學習曲線：預設佈局與 Windows 相似，讓新使用者能快速上手。
• 生產力工具：內建 KRunner（強大的快速啟動與搜尋框）以及先進的視窗平鋪 (Window Tiling) 功能。

💡 提示： 如果你是從 Windows 轉移過來的用戶，KDE Plasma 通常是首選，因為它的操作邏輯最接近傳統桌面。

TUXEDO OS 簡介​

官網 https://www.tuxedocomputers.com/en/TUXEDO-OS_1.tuxedo

TUXEDO OS 是由德國硬體廠商 TUXEDO Computers 所開發的 Linux 發行版。雖然它是為了自家的筆電與桌機進行優化，但它也完全免費開放給所有硬體使用。

核心特色：結合穩定與先進

TUXEDO OS 採取了一個非常聰明的做法：底層採用 Ubuntu LTS (長期支援版) 以確保系統穩定性與商業軟體相容性，但上層桌面環境 (KDE Plasma) 與核心 (Kernel) 則採用類似「滾動更新」的機制，確保使用者能用到最新的功能。

以下是它主要的優勢：

1. 去 Snap 化 (Snap-free by default)：Ubuntu 官方強推的 Snap 套件格式常被批評啟動慢、佔用空間。TUXEDO OS 特地移除了 Snap，改以 Flatpak 作為替代方案。甚至連 Firefox 也是提供原生的 .deb 版本，而不是 Ubuntu 預設的 Snap 版。

2. KDE Plasma 之深度優化：它不僅僅是裝上 KDE，TUXEDO 還對其進行了視覺上的修飾與穩定度測試。它不像 KDE Neon 那樣「過於前衛」導致崩潰，也不會像 Kubuntu 那樣「過於陳舊」。

3. TUXEDO Control Center (TCC)：這是系統的靈魂工具，可以讓你直接在桌面端調整風扇控制（靜音或效能模式）、限制 CPU 功耗 (TDP) 以及即時監控硬體狀態。

4. TUXEDO Tomte & Chroot：Tomte 是一個自動系統小助手，會自動檢查並修補驅動或系統配置問題；而內建的 Chroot 功能則讓你在系統更新出問題時，能透過 Live USB 快速修復引導。

5. 隱私與安全：作為歐洲廠商，TUXEDO 不包含任何遙測或追蹤代碼，給予使用者完全的控制權。

總結： 如果說 Ubuntu 是穩定的老牌企業，KDE Neon 是技術狂的實驗室，那麼 TUXEDO OS 就是一家追求穩定但不失創新、且更懂使用者痛點的精品店。

Linux 至今難解難題​

1. 網路 ATM (晶片卡讀卡機) 這對於台灣的使用者來說是極為現實的痛點。雖然現在行動支付與 App 轉帳很發達，但若需要用到實體讀卡機進行線上轉帳、報稅、或查詢餘額時，大多數銀行的 WebATM 元件依然只支援 Windows (及少部分 macOS)。雖然 Linux 底層可以透過 pcscd 驅動讀卡機，但因為銀行不提供對應的 Linux 元件，導致瀏覽器無法與硬體通訊。這意味著在 Linux 上，你幾乎無法使用實體晶片卡進行任何線上金融操作。

2. 專業軟體與 Office 相容性 這就是最常被提起的「相容性大山」。雖然 Linux 有很好的替代方案（如 LibreOffice,OnlyOffice），對於一般文書處理綽綽有餘，但一旦涉及複雜的 Excel 巨集 (VBA)、特殊的字體渲染、或是需要與他人協作高度精準的 Word 排版時，Linux 方案往往會出現「跑位」或功能缺失。雖然現在可以靠 Web 版 Office 365 解決部分問題，但在功能完整度與操作流暢感上，原生 Windows 版的 Office 依然是難以取代的標準。

how to use local account​

press Shift + F10, type oobe\bypassnro

1. 問題現象 (Symptoms)

• 系統環境： Linux (Tuxedo OS / Ubuntu 24.04 系), Kernel 6.17+。
• 硬體規格： Intel Lunar Lake 平台, Realtek ALC294 Codec, Cirrus Logic CS35L41 (CSC3551) 喇叭放大器。
• 錯誤日誌：
  • cs35l41-hda ... Enable(1) failed: -110 (晶片啟動逾時)。
  • Falling back to default firmware (找不到硬體專用韌體)。
  • Cannot Initialize Firmware. Error: -2 (找不到韌體檔案或格式錯誤)。

2. 核心原因 (Root Causes)
3. 型號 ID 不匹配： 筆電的子系統 ID 為 10431f63，但系統內建韌體庫僅包含 10431f62 的檔案。
4. 韌體壓縮問題： 部分核心驅動程式在初始化 CS35L41 放大器時，無法正確解壓 .zst 格式的韌體，導致載入失敗。
5. 音效拓撲識別： 核心預設未將此型號識別為華碩專用的音效配置，導致喇叭放大器未被正確供電。
6. 硬體狀態鎖定： 放大器晶片在多次載入失敗後會進入保護模式，需透過完全斷電（Cold Boot）重置。

3. 完整解決方案 (The Solution)

第一步：處理韌體檔案 (解壓與匹配 ID)​

必須讓系統找到未經壓縮、且符合 1f63 編號的韌體檔案。

    1 # 1. 進入韌體目錄
    2 cd /lib/firmware/cirrus/
    3
    4 # 2. 解壓縮所有 .zst 檔案 (確保核心能讀取原始格式)
    5 sudo zstd -d --rm *.zst 2>/dev/null
    6
    7 # 3. 建立 1f63 的連結 (指向 1f62 的原始檔案)
    8 sudo ln -sf cs35l41-dsp1-spk-cali-10431f62.wmfw cs35l41-dsp1-spk-cali-10431f63.wmfw
    9 sudo ln -sf cs35l41-dsp1-spk-prot-10431f62.wmfw cs35l41-dsp1-spk-prot-10431f63.wmfw
   10 sudo ln -sf cs35l41-dsp1-spk-cali-10431f62-spkid0-l0.bin cs35l41-dsp1-spk-cali-10431f63-spkid0-l0.bin
   11 sudo ln -sf cs35l41-dsp1-spk-cali-10431f62-spkid0-r0.bin cs35l41-dsp1-spk-cali-10431f63-spkid0-r0.bin
   12 sudo ln -sf cs35l41-dsp1-spk-cali-10431f62-spkid1-l0.bin cs35l41-dsp1-spk-cali-10431f63-spkid1-l0.bin
   13 sudo ln -sf cs35l41-dsp1-spk-cali-10431f62-spkid1-r0.bin cs35l41-dsp1-spk-cali-10431f63-spkid1-r0.bin
   14 sudo ln -sf cs35l41-dsp1-spk-prot-10431f62-spkid0-l0.bin cs35l41-dsp1-spk-prot-10431f63-spkid0-l0.bin
   15 sudo ln -sf cs35l41-dsp1-spk-prot-10431f62-spkid0-r0.bin cs35l41-dsp1-spk-prot-10431f63-spkid0-r0.bin
   16 sudo ln -sf cs35l41-dsp1-spk-prot-10431f62-spkid1-l0.bin cs35l41-dsp1-spk-prot-10431f63-spkid1-l0.bin
   17 sudo ln -sf cs35l41-dsp1-spk-prot-10431f62-spkid1-r0.bin cs35l41-dsp1-spk-prot-10431f63-spkid1-r0.bin

第二步：配置核心參數​

強制驅動程式使用適合華碩 ExpertBook 系列的音效模型。

1 # 建立/修改音效配置檔案 2 echo "options snd-hda-intel model=alc294-asus-p50" | sudo tee /etc/modprobe.d/alsa-base.conf 3 4 # 更新 initramfs (確保開機掛載) 5 sudo update-initramfs -u

第三步：手動解除底層靜音 (ALSA)​

解除硬體暫存器中的強迫靜音狀態。

   1 # 根據 amixer contents 找到的 numid 進行操作
   2 amixer -c 0 cset numid=3 0  # 關閉 Forced Mute L
   3 amixer -c 0 cset numid=6 0  # 關閉 Forced Mute R
   4 amixer -c 0 cset numid=10 on # 開啟 Speaker Switch
   5 amixer -c 0 cset numid=9 87  # 調高 Speaker Volume

第四步：完全斷電重置 (Cold Boot)​

這是最關鍵的一步：

• 關機，拔掉電源線。
• 靜置約 10 秒（讓放大器晶片完全失去電力以清除錯誤狀態）。
• 重新接電開機。

4. 未來維護建議

• 核心更新： 之後若更新核心（例如升級到 6.18+），若發現聲音消失，請檢查 /etc/modprobe.d/alsa-base.conf 是否還在。
• 韌體包更新： 若 linux-firmware 套件更新，可能會重新下載 .zst 檔案，屆時可能需要重新執行「解壓縮」的動作。

這份紀錄可以保存在您的雲端筆記或 /etc/ 備份中，方便日後重裝系統時參考。很高興能幫您解決問題！

考前準備​

CKA, CKAD 是實做測驗
不外乎就是要熟相關 command, document
但不用死記(應該也沒什麼人能夠記的住)
考試中能夠開 document
因此官網務必要熟悉, 測驗中才能順利翻找資料

學習資源

• https://github.com/sailor-sh/CK-X : 社群製作的模擬器, 但答案判斷機制有點怪, 另外平台很舊, 有待更新
• udemy 課程: 很推薦買 不貴,內容充實,終生,又持續更新, 未來 k8s 新功能也能當學習來源
• killercoda.com: 有些情境可以看
• killer.sh: 考試會送 2 次模擬考, 難度比實際實際考試難,能過基本可以穩拿證書
• k3s: 基本上考試中也幾乎是用 k3s 了, 自架環境練習非常好用, 不建議使用 kind 因為 kind 會受 docker overlap 影響, 實際使用會有出入

考試環境注意事項​

因為考試規則會改變
務必閱讀官方說明
官方說明說的非常詳細, 比如說過程可以使用哪些資源

考試中可以使用VSCodium
因此不必擔心改 yaml 會很痛苦

這邊補充幾點
考試必須使用 PSI Secure Browser
但他在 ubuntu 與 snap 會衝突 PSI secure browser installer crashed
另外我也遇到 text 無法複製問題
因此強烈建議避免使用 linux 考試 (這對 linux foundation 有點諷刺...)

QA​

Q. 考試中 browser 只能開兩個分頁？
A. 目前無此限制

也等同正式宣告 minIO 要轉向閉源了
雖然在早前就有跡象
但這次變更也意味著社群要正式開始尋找替代方案了

[!NOTE] cephFS 不在我的考慮範圍內, 幾個原因

• object storage 與 block storage 目標並不同, cephFS 當 object storage 太浪費了
• cephFS 複雜的部屬需求並不適合用在開發/ CICD 環境

以下嘗試用 google notebookLM 幫忙快速分析替代方案

S3 相容物件儲存詳細比較 (MinIO, RustFS, SeaweedFS, Garage)​

I. 核心架構與資源效率​

II. 性能指標與專業化​

III. S3 兼容性與進階功能​

IV. 授權與社群狀態 (商業考量)​

另外補充 https://www.repoflow.io/blog/benchmarking-self-hosted-s3-compatible-storage-a-practical-performance-comparison

rustFS 目前來說還是 alpha 階段 不建議此時採用
且他是具有中國色彩 就算 stable 後 個人也是不建議採就用

SeaweedFS 嚴格上來說與 cephFS 有點像, 只是額外提供 S3 compatible
這樣看來 garage 算是替代 minIO 較好的選擇

因此 接下我來會著手替換手上的 minIO to garage
之後再寫篇文章介紹 garage

只要補上 config 即可解決

解決方法一 - 手動編輯 config​

[Wayland]
InputMethod[$e]=/usr/share/applications/org.fcitx.Fcitx5.desktop

解決方法二 - 透過 system settings 自動新增 config​

打開 system settings - Keyboard - Virtual Keyboard
選擇 Fcitx5 (預設是 None) > Apply

選擇其中一種方法
重新登入後即可解決

Introduction​

不管是個人還是在團隊中
文件都是相當重要的一環
可以是筆記性質, 也能是 SOP, 也能是 share doc

而這些需求的背後, 就是要一個文件平台
儘管現成有 google drive, Dropbox, OneDrive, notion, HackMD 這類平台可以使用
但仍沒一套能夠滿足需求

我的需求如下

• support markdown (best is WYSIWYG, which stands for "What You See Is What You Get")
• collaborative
• permission control
• Single Sign-On
• self-host

於是尋找一套能夠滿足需求的 tool 是我最重是的目標

history of chose tool​

在這之前, 我曾使用過 google drive, Dropbox, OneDrive, notion, HackMD
以下稍微說明我不選擇的理由

HackMD​

HackMD 雖然很知名, 其也有 open-source 方案 (hedgedoc,CodiMD)
我在之前是使用 hedgedoc, hedgedoc 跟 CodiMD 之間是有點故事的
關於 hedgedoc 跟 CodiMD: https://hedgedoc.org/history/

在這幾年的追蹤下, 原本 HackMD 沒什麼在維護 CodiMD
這也是我採用 hedgedoc 的理由
結果最近反轉了, hedgedoc 2 的進度一直 delay,讓人很懷疑到底還有沒有在繼續開發
反而 CodiMD 開始積極在更新
真讓人摸不著頭緒

但一直讓我很不滿意的是左右兩欄的設計很占版面, 如果能支援 WYSIWYG 就好了
這就是我很想再令尋他套的理由

Dropbox​

唯一有印象的就是當文件稍大, performance 就變很差
且也不算支援 markdown, 雖然 Paper 能使用部份 markdown 語法

notion​

唯一挑替的就是要付錢了
不然絕對是首選 knowledge system

sharepoint​

商業方案 但其 office 超難用...
反而 google doc 好用的多
對 markdown 支援超差
最要命的是搜尋功能超扯, 基本上根本找不到 ('keyword' 用 'key' 去搜尋會找不到... ,必須使用完整 string 'keyword')
不知道為什麼微軟的系統搜尋都超爛... 像是 outlook 也是常常找不到東西
還有些很奇怪的邏輯
舉例用搜尋找到的文件千萬不能用編輯功能(sharepoint 會幫你另存新檔 WTF...)

是我接觸過 document 平台用的最不爽的

wiki​

wiki 有很多套
然而大部分都不理想, 就不贅述了

what is outline​

official site

簡單來說 就是一個跟 notion 很像的系統
對於我想要的功能都支援了

• support markdown (WYSIWYG mode)
  很大程度降低編寫文件的困擾
• collaborative
  在 team 中使用最重要的功能
• Single Sign-On
  管理帳號方便的多
• permission control
  能夠避免權限外洩
• self-host
  可以安全在 private network 使用
• history
• comment
• support mermaid diagram

至於實際還有那些功能
可以先使用其 cloud 版本體驗看看

想要 self-host 可以參考 doc hosting-outline
不過請再注意功能上會有稍微差異 pricing

Conclusion​

俗話說 萬丈高樓平地起
document system 是我認為最重要的基本生產力工具
一旦沒有好用的系統
不只自身筆記難以紀錄(沒人可以記所有東西)
也很難在團隊之間分享知識
進而導致自己/團隊生產力低下

Prologue​

這篇分享我在團隊內導入 On-Call System 的過程
裡面包含我們的需求
所以不是什麼 best practice
不會適用每個團隊
採用前請大家做好評估

身為一個系統管理者
為了要讓系統能不間斷的提供服務
除了高可用性外
有人 on-call 也是很重要的
就算有 HA / auto-recovery
然而再怎麼樣
系統還是有可能有需要人介入的狀況
因此有 monitor 就會有 alert 的需求
但是光有 alert 其實還不夠
我們可能會希望 alert 要能夠支援類似 phone-call
還要根據 team member 排班有各自的通知對象

因此 on-call system 就有它的存在性

On-Call System 目標​

下列出我們的需求

• 接收 alert
  至少支援 webhook
• 發送 alert
  至少支援
  • call-out (phone-call)
  • webhook
• 支援排班
• 提供 free tier
  因我們本來就有 on-call 工具，只是很陽春，所以希望在不增加 cost 情況下
  加強我們的 call-out
• Alert Suppression
  避免被 alert 轟炸

On-Call System Comparison​

在經過 Google Search 後
列出當時幾個系統的評估
但有可能有錯/改變
各位務必再評估過

last update: 2025/06/17

• alertops
  free tier 5 users
  難以理解,不會用
  沒有 per-service integration
  要等試用期結束才能切免費
  app 功能普通 沒有 ack 機制

• pagerduty
  free tier 5 users
  Integrations 可以整合 Outbound Integration (e.g., trigger webhook)
  free 可以用 schedule override
  but On-call Schedules 只能 1 個，因此無法分 primary/secondary member

• taskcall
  free tier 5 users
  沒辦法匯出 schedules
  Web UI 有點慢

• atlassian opsgenie
  free tier 5 users
  跟 zenduty 比限制較少
  API 有 Request Limits 怕 alert 發不出來
  free tier Routing Rules 沒辦法分 service
  多 incident per service 不知如何應用

• grafana OnCall
  a part of Grafana Cloud IRM
  free tier 3 users
  整合 Grafana 生態系，方便現有 Grafana 用戶

• zenduty
  free tier 5 users
  override schedule 須付費才能使用
  換班較麻煩
  Android/iOS app 好用，會發 alert (像國家警告系統那樣，有 phone-call 效果，而不是單純的訊息通知)
  web, app 反應稍慢

• xmatters
  free tier 10 users
  region 有亞太 (反應比較快)
  Outbound Integration 很現代感
  有點小複雜,需要時間學習

• squadcast
  free tier 5 users
  Android/iOS app 好用，會發 alert
  免費有 override schedule
  也有 Analytics
  web, app 反應快上不少
  跟 zenduty 比感覺更好用

評估結果
依功能評估：xmatters > opsgenie > squadcast > zenduty
依實用性評估：squadcast > zenduty > xmatters > opsgenie

why chose squadcast​

最後我們採用了 squadcast 來增強我們既有的 on-call system

以下列出採用原因

• free tier 5 user
  對於 small team 的我們夠用
• Push Notifications is Unlimited
  不怕頂到 limit 變成通知發不出來
• phone call 用完就沒了
  跟其他家不同 其他都是 Monthy limit
  不過這點不影響, 因為其他家 free-tier quoda 也不多
  都是不夠用的情況
  這部份仰賴我們既有的 call out system
• Native Integrations with Alert Sources & Custom Integrations via API
  除了原生整合 alert source 外
  也能 call API
  讓系統不受限制
• On-Call Schedules
  最重要的 就是排班機制
  他能夠設定多個 Schedules
  我們設定了 primary & backup
  如果 primary 意外沒收到 alert, backup 可以處理
• Schedule Overrides
  如果 on-call member 有事 能夠 Overrides schedules 讓其他 member 暫時 on-call
  而不需要重新調整排班
  舉例來說 member 輪班 interval 是一週
  Schedules 會設定為 routing 的狀態

而有人請假的話 就可以使用 Overrides 功能
而不用修改 Schedule

• Escalation Policies
  因為 squadcast 收到 alert 時會有幾個階段

前面提到 Schedules 我們設定了 primary/backup
如果 primary member 沒接到 alert
這裡可以設定時間經過 N 分鐘後, 如果沒有人 acknowledge 的話
就通知 backup member
這也是當初要找 on-call system 最想要的功能

• Alert Deduplication
  當 alert 發生時 相關的 service 受影響的話可能也會發 alert
  Dedup 可以避免 oncall member 一直收到 notify 而無法專心處理 alert

• API Request Unlimited Limits
  如果有 limit 的話會擔心 alert 送不出來
  這點也是加分

• Mobile App (Android & iOS)
  他們有自己的 APP
  APP 能夠設定 "Bypass Do Not Disturb"
  避免因手機設定沒收到 alert
  其效果就像國家警報系統 極盡可能讓你避免 alert 未收到
  幾乎可以直接取代 phone-call

• 能夠整合 Slack

• 能夠設定多個 Services
  不同 service 會有不同的 on-call member
  也能接各自的 alert source & target (比如說不同 slack channel)

• MTTA / MTTR Performance Report & User and Incident Based Analytics & Organization and Team Based Analytics
  老闆最愛看

以上就是我們嘗試導入 on-call system 的原因
另外 squadcast 不只功能符合我們需求
其速度也很優
app notify 會比 phone call 還快
這點個人超驚訝

最後再次強調 這不是業配 單純導入心得分享
請大家再根據 team 需求選擇對應的系統

official site: https://developer.hashicorp.com/vagrant

Vagrant 是一個強大的開源工具，用於建立和管理輕量級、可攜式且可重複使用的開發環境。它透過自動化虛擬機的配置，讓開發者能夠在統一的環境中工作，無論團隊成員使用何種作業系統。

為什麼選擇 Vagrant？​

在軟體開發中，環境一致性是提高效率和減少「在我的機器上可以跑」問題的關鍵。Vagrant 解決了以下痛點：

• 環境差異： 告別不同作業系統、函式庫版本或配置差異導致的問題。
• 快速設定： 新團隊成員或新專案啟動時，不再需要耗費數小時甚至數天來設定開發環境。
• 可重複性： 確保每次建立的環境都完全相同，有利於測試和部署。
• 資源隔離： 將開發環境與主機系統隔離，避免軟體衝突。
• 版本控制： Vagrantfile 可以像程式碼一樣被版本控制，方便追蹤環境變更。

對於 DevOps 和 SRE 專業人員來說，Vagrant 更是不可或缺的工具，它能幫助快速建立、測試和銷毀基礎設施環境，加速開發流程。

核心概念​

在深入使用 Vagrant 之前，了解幾個核心概念至關重要：

• Box (基礎映像檔): Vagrant 的基礎，類似於虛擬機的模板或快照。它是一個預先安裝好作業系統的虛擬機映像檔，Vagrant 會基於這個 Box 建立新的虛擬機。這比從 ISO 安裝作業系統快得多。
• Provider (虛擬化供應商): 執行虛擬機的底層技術。Vagrant 預設支援 VirtualBox，但也支援 VMware、Hyper-V、Docker 等。雖然支援多種供應商，但為了避免相容性問題和簡化設定，建議初學者優先使用 VirtualBox。
• Vagrantfile (配置檔): Vagrant 的核心，一個 Ruby 語言撰寫的配置檔。它定義了虛擬機的各種設定，包括使用的 Box、網路配置、共享資料夾、資源分配以及自動化腳本（Provisioners）。
• Provisioner (自動化配置工具): 用於在虛擬機啟動後自動安裝軟體、配置系統或執行腳本。Vagrant 支援 Shell Script、Ansible、Chef、Puppet 等多種 Provisioner，確保開發環境的自動化配置。

快速入門​

以下是使用 Vagrant 建立第一個虛擬機的基本步驟：

1. 安裝 Vagrant: 從 Vagrant 官方網站 下載並安裝適合您作業系統的版本。

2. 安裝 VirtualBox: Vagrant 預設使用 VirtualBox 作為虛擬化供應商。請從 VirtualBox 官方網站 下載並安裝。

3. 建立 Vagrantfile: 在您專案的根目錄下建立一個名為 Vagrantfile 的檔案。這是定義虛擬機配置的地方。

   # -*- mode: ruby -*-
   # vi: set ft=ruby :
   
   Vagrant.configure("2") do |config|
     # 指定使用的 Box，這裡使用 Ubuntu 20.04 LTS (Bionic Beaver)
     config.vm.box = "hashicorp/bionic64"
   
     # 配置虛擬機的網路，這裡設定一個私有網路，IP 為 192.168.56.101
     # 這樣可以從主機直接透過 SSH 連線到虛擬機
     config.vm.network "private_network", ip: "192.168.56.101"
   
     # 配置虛擬機的資源，例如 CPU 和記憶體
     config.vm.provider "virtualbox" do |v|
       v.memory = 2048 # 2GB 記憶體
       v.cpus = 2      # 2 個 CPU 核心
     end
   
     # 使用 Shell Provisioner 在虛擬機啟動後執行命令
     # 這裡示範更新套件列表並安裝 Nginx
     config.vm.provision "shell", inline: <<-SHELL
       sudo apt-get update
       sudo apt-get install -y nginx
       echo "Hello from Vagrant!" | sudo tee /var/www/html/index.nginx-debian.html
     SHELL
   end
   

4. 啟動虛擬機: 在 Vagrantfile 所在的目錄執行 vagrant up 命令。Vagrant 會自動下載 Box（如果尚未下載）、建立虛擬機並執行 Provisioner。

   vagrant up
   

5. 連接虛擬機: 虛擬機啟動後，您可以使用 vagrant ssh 命令透過 SSH 連接到虛擬機。

   vagrant ssh
   

6. 清理環境: 當您不再需要虛擬機時，可以使用 vagrant destroy -f 命令銷毀虛擬機及其所有相關檔案。

   vagrant destroy -f
   

進階技巧​

1. 建立自訂 Box​

雖然 Vagrant Cloud 上有許多現成的 Box，但在實際開發中，您可能需要一個預先安裝好特定軟體（如 Python、Node.js、資料庫等）的自訂 Box。這可以大幅縮短每次 vagrant up 的時間。

步驟概覽：

1. 在 VirtualBox 中手動建立一個虛擬機，安裝作業系統和所有必要的軟體。

2. 清理虛擬機（例如，移除歷史記錄、壓縮磁碟）。

3. 使用 vagrant package 命令將虛擬機打包成一個 .box 檔案。

   vagrant package --base <VirtualBox VM Name> --output custom.box
   

4. 將自訂 Box 添加到 Vagrant。

   vagrant box add custom-box custom.box
   

5. 在 Vagrantfile 中使用您的自訂 Box。

   config.vm.box = "custom-box"
   

詳細步驟請參考 Vagrant 官方文件：建立基礎 Box。

2. 網路配置​

Vagrant 提供了多種網路配置選項，以滿足不同的需求：

• NAT (預設): 虛擬機可以訪問外部網路，但外部網路無法直接訪問虛擬機。適合簡單的開發環境。

• Private Network (主機專用網路): 建立一個僅限主機和虛擬機之間通訊的網路。常用於設定固定 IP，方便主機上的其他工具（如 IDE、資料庫客戶端）連接虛擬機。

  config.vm.network "private_network", ip: "192.168.56.101"
  

• Public Network (橋接網路): 讓虛擬機像獨立的實體機器一樣連接到您的區域網路，擁有自己的 IP 位址。適合需要從外部網路訪問虛擬機的場景。

  config.vm.network "public_network"
  

• Port Forwarding (連接埠轉發): 將主機上的特定連接埠轉發到虛擬機上的連接埠，允許從主機或外部網路訪問虛擬機上運行的服務。

  config.vm.network "forwarded_port", guest: 80, host: 8080 # 將虛擬機的 80 埠轉發到主機的 8080 埠
  

3. 管理多個虛擬機 (Multi-Machine)​

Vagrant 的真正價值在於能夠在一個 Vagrantfile 中定義和管理多個虛擬機，這對於模擬分散式系統、叢集或多層應用程式架構非常有用。

# -*- mode: ruby -*-
# vi: set ft=ruby :

$num_vms = 3 # 定義要建立的虛擬機數量
$vm_cpus = 2 # 每個虛擬機的 CPU 核心數
$vm_memory = 2048 # 每個虛擬機的記憶體大小 (MB)

Vagrant.configure("2") do |config|
  # 設定所有虛擬機共用的 Box
  config.vm.box = "hashicorp/bionic64" # 或者使用您自訂的 "custom-box"

  # 設定 SSH 登入憑證 (如果 Box 需要)
  config.ssh.username = "vagrant" # 預設的 Vagrant Box 通常使用 'vagrant'
  config.ssh.password = "vagrant" # 預設的 Vagrant Box 通常使用 'vagrant'

  # 配置 VirtualBox 供應商的通用設定
  config.vm.provider "virtualbox" do |v|
    v.linked_clone = true # 啟用連結複製，節省磁碟空間和加速建立
    v.gui = false         # 不顯示 VirtualBox GUI
  end

  # 使用迴圈建立多個虛擬機
  (1..$num_vms).each do |i|
    config.vm.define "node#{i}" do |node|
      node.vm.hostname = "node#{i}.example.com" # 設定虛擬機的主機名稱
      node.vm.network "private_network", ip: "192.168.56.#{100 + i}" # 設定私有網路 IP

      # 為每個虛擬機配置資源
      node.vm.provider "virtualbox" do |v|
        v.cpus = $vm_cpus
        v.memory = $vm_memory
      end

      # 為每個虛擬機執行 Provisioner
      node.vm.provision "shell", inline: <<-SHELL
        echo "Setting up node#{i}..."
        # 在這裡添加每個節點特有的配置腳本
        # 例如：安裝 Docker, Kubernetes 元件等
      SHELL
    end
  end
end

4. 連結複製 (Linked Clones)​

當您需要建立多個虛擬機時，使用連結複製（Linked Clones）可以顯著節省磁碟空間和加速虛擬機的建立過程。連結複製的虛擬機共享一個基礎映像檔，只儲存與基礎映像檔不同的部分。

在 Vagrantfile 中啟用連結複製非常簡單：

config.vm.provider "virtualbox" do |v|
  v.linked_clone = true
end

總結​

Vagrant 是一個強大的工具，能夠簡化開發環境的建立和管理，提高團隊協作效率。透過理解其核心概念並善用進階功能，您可以為任何專案建立穩定、可重複且高效的開發環境。

希望這篇文章能幫助您更好地理解和使用 Vagrant！

Introduction​

hugo 是一個 static site generator
除了找 web server 外
也可以使用 github page 來 host

一般的 web server 都會提供 php,DB 等來讓 web 能進行動態功能
但是缺點是需要額外的 knowhow 且有更新/漏洞等問題
隔壁的 wordpress 就是

因為 hugo 是產生 static site 可以說相對單純容易維護, 不過當然也會有功能較差的問題
因此 static site 也是有一部份支持者
也越來越多網站採用此設計

github page​

由 github 提供的服務
讓大家能夠放上 static site
不僅速度快又不用錢
又能配合將 source code 放在 github 中做儲存/版控
是個工程師很愛的地方, 本站也是採用 github page 做 host

開始前
github page 讀取 static content 有兩種方式

• repo
• artifact

採用 repo 方式會相對簡單, 但既然身為一個工程師
CICD 的玩法才是有趣的目標🤓
於是這邊採用 artifact(github action) 幫忙執行 build/upload artifact/deploy page

setup cicd​

setup github runner​

github runner 就是在執行 workflow 的 worker
可以使用 github 的免費額度
或是使用 self-host runner
因為我自己有台 VPS, 所以採用 self-host runner
另外因為 self-host runner 是採用 per repo
建議建立一個 organization, 在這可以建立 runner group,就可以一個 self-host runner share 給多個 repo 使用

self-host runner 再使用 systemd 帶起
就可以不必每次開關機 VM 都還要手動帶起了

systemd config

# /etc/systemd/system/actions-runner.service
[Unit]
Description=GitHub Actions Runner
After=network.target syslog.target

[Service]
ExecStart=bash run.sh
WorkingDirectory=/home/github-runner/actions-runner
User=github-runner
Group=github-runner

Restart=always
RestartSec=10s
StandardOutput=journal
StandardError=journal
SyslogIdentifier=actions-runner
KillMode=process
TimeoutStopSec=5min # Give it time to finish a job or shut down gracefully

[Install]
WantedBy=multi-user.target

setup repo​

因為採用 cicd 方式
我們的 repo 不保留 public folder (generate by hugo)
此 folder 為最後 hugo 產生的 static content, 這個要交由 github runner 產生

在 .gitignore 加上 public/ 解決 .gitignore

setup github workflow​

在這一步我們要告訴 gitlab runner 要做什麼
請參考 workflow

簡單來說就是

• checkout main branch (github page limit)
• hugo build static file
• upload artifact
• deploy artifact to page

setup page​

再接下來要開啟 page 功能
到 settings/pages
設定 source 為 githab action

這邊建議再申請一個 free dns 設定 Custom domain
因為 page default 會給 <username>.github.io/<repo name>
在 uri 部份會有個 repo name 為 prefix
在部份 search engine 最佳化會碰上些問題(之後再細說)

push code​

最後只要 push code 到 main branch
觀察看看 action 狀況即可

Introduction​

static site 表示這個 site 單純依靠 HTML,CSS 和 JavaScript 組成
server 只負責存放(host) 這些內容(file)
browser(client) 進行渲染(render)
server 不會進行任何動態行為, 比如說存取 DB

靜態網站的優點： 速度快： 因為內容是預先準備好的，伺服器可以直接傳送，載入速度通常非常快。
安全性高： 由於沒有複雜的後端程式碼和資料庫直接暴露給用戶請求，被攻擊的風險較低。
成本低： 靜態檔案對伺服器的資源要求不高，所以託管成本通常更便宜，甚至有很多免費的託管服務（如 GitHub Pages, Netlify, Vercel）。
可靠性高/易於擴展： 由於結構簡單，伺服器壓力小，更容易應對大量訪問，並且可以輕鬆地使用 CDN（內容傳遞網路）來加速全球訪問。
開發和維護相對簡單（對於某些類型的網站）： 對於內容不常變動的網站來說，開發和維護可能更直接。
靜態網站的缺點/限制： 互動性有限： 如果需要複雜的用戶互動（如用戶登入、留言板、線上購物等需要後端處理的功能），純靜態網站本身無法實現，需要依賴第三方服務或 JavaScript 來模擬。
內容更新不便（傳統方式）： 如果沒有使用現代化的工具，每次更新內容可能都需要手動修改 HTML 檔案，然後重新上傳，對於非技術人員來說比較麻煩。

評估系統 hugo & Docusaurus​

兩者都是使用 markdown 書寫

Docusaurus​

https://docusaurus.io
Docusaurus 產生網站速度較慢 (but who care)
但上手難度較高, 建議需要基本 js/ts 能力, plugin/theme 支援較少

支援 git 版控 比較適合 doc 類網站

hugo​

https://gohugo.io
較單純 基本 toml/markdown knowledge 即可, theme 非常多
較適合做網站/blog

conclusion​

因為我比較需要 blog 形式
hugo 的 theme 給我較快速上手的能力
另外社群擴充功能也比較豐富
與 wordpress 相比 hugo 的輕量化也讓效率大幅提昇
wordpress 就是給人一種沈重的感覺
於是採用 hugo 作為我的 static blog system