萌芽系列網站在今年九月剛滿十五週年，伺服器的底層架構多年來也隨著技術演進不斷翻新。目前主力運作在 VPS 上的作業系統原先維持在 Ubuntu 24.04 LTS，隨著今年 Ubuntu 26.04 LTS 推出且迎來首個小版本修正，衡量長期安全性更新與系統底層函式庫支援度後，便決定挑選離峰時段進行跨大版本的原地升級（do-release-upgrade）。整個升級過程算是有驚無險，除了再次印證近年全面導入容器化架構的明智抉擇，也接連踩到了暫存目錄清理與 Python 模組相依性這兩大經典暗坑。
談到這次升級最省心的地方，莫過於萌芽系列網站旗下包括萌芽綜合天地、爬山網、悠遊網等各子站的核心服務，早已全面透過 Docker 與 Docker Compose 進行容器化部署。無論是 OpenLiteSpeed、PHP 8.4 環境還是 MySQL 資料庫，甚至是各項客製化的微服務，都與主機作業系統完全解耦。因此當底層升級完成、套件依賴庫全部替換完畢後，容器環境幾乎是無縫開機重啟，原本令人擔憂的資料庫相容性或 PHP 模組斷層完全沒有發生。容器化為站長省下了重編譯環境與逐一修復相依套件的大量心力，也是本次維運能迅速穩住大局的關鍵基石。
然而，主機層級的宿主服務就沒這麼幸運了。擔任最外層反向代理與快取中樞的 Nginx，在伺服器完成升級重開機後直接罷工，導致所有對外網頁瞬間失去回應。查看系統日誌才發現，Nginx 啟動時回報找不到 /tmp/nginx/cache 目錄而拒絕載入。追查後確認，這是因為原本將高效能快取目錄指向 /tmp，但現代 systemd 在開機掛載時會全面重置該暫存空間；加上升級過程重構了部分系統層級權限，導致缺少快取目錄的 Nginx 直接 Crash。手動建立目錄固然能短暫拉起網站，但只要下次主機重啟又會打回原形。為此想到的做法是建立 tmpfiles.d 規則，讓系統在開機掛載暫存目錄的同時，自動以正確的 www-data 權限重建專屬快取層次結構：
# /etc/tmpfiles.d/nginx-cache.conf
d /tmp/nginx 0755 www-data www-data -
d /tmp/nginx/cache 0700 www-data www-data -本以為搞定 Nginx 後就能高枕無憂，沒想到例行檢查 SSL 憑證排程時，執行 certbot renew 竟然直接噴出 ModuleNotFoundError: No module named 'certbot' 錯誤。問題根源在於 Ubuntu 跨版本升級時，系統預設的 Python 版本隨之更新，導致原本安裝在舊版 Python 路徑下的 Certbot 模組未被同步遷移，而 /usr/bin/certbot 啟動腳本卻已經切換到新版 Python 直譯器，最終引發載入崩潰。要解決這個環境斷層，除了改用自帶獨立 Runtime 沙盒的 Snap 官方推薦方案外，也可以直接透過 apt install --reinstall -y python3-certbot certbot 強制將模組重新編譯對齊當前的新 Python 環境。修復後透過 dry-run 再次驗證，主機上管理的多組子網域均成功讀取 renewal 設定，且正確遵循三十天內才觸發更新的保護機制，確認 SSL 工具鏈已完全恢復健康。
在解決了 Nginx 快取暗坑與 Certbot 模組斷層後，剩下的便是一些內部自用服務的零星維護。由於自建的遠端管理通道同樣運行於容器內，在系統升級後順手針對過期的安全憑證進行了重新展延，並微調了新版作業系統核心協議的握手參數，確保遠端維護網路順暢無阻。考慮到主機安全性，內部連線拓撲與驗證細節在此便不多做贅述，只要掌握原則：容器外層防火牆精確限縮、定時輪替金鑰，就能兼顧管理彈性與伺服器防禦力。
回顧這次從 Ubuntu 24.04 升級至 26.04 的過程，整體體驗瑕不掩瑜。將網站應用層全數推進 Docker 容器，讓跨版本的系統升級風險降低了八成以上；而剩下的兩成，往往就是考驗站長對 systemd 生命週期與 Python 依賴庫細節的掌控度。每一次的踩坑與填坑，都是為了讓萌芽系列網站在下一個年頭能持續以高效率、安全、穩定的狀態陪伴每一位訪客。
《上一篇》Gemini 4 Argon：長程深度推理帶動軟體工程與資安防禦新典範 
《下一篇》WSL 3 登場：微軟深度整合 Linux 容器，告別繁複環境與跨系統效能瓶頸 
留言區 / Comments
萌芽論壇