平台與維運 2026 年 6 月 23 日

2026-06-23 — OpenTofu ChatOps、Guix 遷 Codeberg 一年、GIMP Flatpak

primary=https://techblog.lycorp.co.jp/en/techverse2026-86 primary=https://guix.gnu.org/en/blog/2026/one-year-with-codeberg/ primary=https://consensus.guix.gnu.org/gcd/002-codeberg.html primary=https://lwn.net/Articles/1078969/

從 IaC 到 AI:LINE Plus SRE 以 OpenTofu 與 ChatOps 管理 1,500 個雲端資源

LY Corporation Tech Blog · 2026-06-22

LINE Plus SRE 團隊在 2026 年 Tech-Verse 大會上分享,他們如何將旗下七個服務的約 1,500 個雲端資源全面納入以 OpenTofu 1.12 和 Terragrunt 構成的 IaC 管道,並進一步整合 AI 代理人,讓工程師得以用自然語言在 Slack 發起基礎設施變更。這套架構最終涵蓋約 300 台虛擬機、160 個負載平衡器、350 筆 DNS 記錄,以及 Kubernetes 資源和 IMON 監控告警規則。

原本的問題

在遷移之前,各服務的雲端資源分散由人工在控制台建立,缺乏統一的版本控制與審查流程。最棘手的挑戰在於如何區分手動建立的 VM 與 Kubernetes 自動產生的節點,以及如何處理 IMON 的多層告警樹狀結構(團隊 → 群組 → 規則 → 監控器),這兩者都不適合以標準 import 流程直接處理。程式碼、state 檔案與實際雲端資源三方之間的狀態漂移,也需要事先正規化才能建立穩定的基準。

採用的方法

遷移分兩個階段進行。第一階段針對試點服務開發自動化 import 腳本,並貢獻上游 provider 以修正驗證問題;第二階段複用第一階段的模板,快速擴展至其餘六個服務。選擇 OpenTofu(Terraform 的開源分支,由 Linux Foundation 治理)搭配 Terragrunt 作為 DRY wrapper,是因為兩者能保留現有 HCL 語法與 provider 相容性。GitOps 管道的日常流程如下:

  • 開 PR 時自動執行 tofu plan 並在 PR 頁面呈現 diff 預覽
  • 合併後自動觸發 tofu apply
  • 每日執行 drift check,偵測繞過 IaC 直接在控制台操作的情況

為了降低學習門檻,團隊開發了一個 Chrome 擴充功能,可從 Web 控制台 UI 直接產生對應的 HCL 程式碼,並定期舉辦名為「Opentalk」的雙週技術分享會。

AI 代理人整合

在 IaC 管道穩定後,團隊透過 Model Context Protocol(MCP)將 OpenTofu 儲存庫與 AI 代理人串接,使工程師能在 Slack 以自然語言提出基礎設施變更請求。代理人接收指令後自動產生 HCL 程式碼、開立 PR,並附上 tofu plan 結果供人工審查;合併後自動部署。告警觸發時代理人也能提供自動修復建議,形成完整的 ChatOps 閉環。

原始來源:LY Corporation Tech Blog — From IaC to AI


GNU Guix 遷移 Codeberg 一週年:共識流程、CI 補缺與貢獻者數據回顧

GNU Guix Blog · 2026-06-22

GNU Guix 專案於 2025 年 5 月 25 日將主儲存庫從 GNU Savannah 遷移至 Codeberg(由德國非營利組織 Codeberg e.V. 營運的 Forgejo 實例),2026 年 6 月 22 日官方部落格發布了完整的一週年回顧。此次搬遷依據 GCD 002 提案,以 72% 贊成、28% 接受的結果通過,並於 2025 年 5 月 7 日正式生效。

核心改動

遷移涵蓋 Savannah 上的全部 15 個儲存庫,以及原本依賴 Debbugs 的電子郵件補丁工作流程。Debbugs 的 issues.guix.gnu.org 保留運作直至 2026 年 1 月 1 日才進入「緊急仲裁」模式,讓貢獻者有充裕時間切換。最關鍵的 CI 缺口是 pull request 自動構建:Quality Assurance service 初期未移植至 Codeberg,直到 2025 年 9 月,一個新的 Cuirass 實例才在 pulls.ci.guix.gnu.org 上線,能在 PR 上自動執行構建並由機器人回報結果。存取控制方面,以 CODEOWNERS 檔案取代原本的 etc/teams.scm,實現子系統自動通知。

影響範圍

根據 2024 年 5 月至 2026 年 5 月的兩年數據,月度提交作者數在 2025 年 6 月遷移後出現峰值,但新貢獻者成長速率在遷移前後並無顯著差異,顯示 Codeberg 本身並非吸引新手的主要因素。PR 方面,每月開立約 500 筆,截至回顧撰寫時共 6,459 筆,其中約 639 筆仍開放(backlog 比率約 10%)。目前仍存在幾個摩擦點:

  • 所有提交必須由列於 .guix-authorizations 的授權提交者簽署,無法全自動合併
  • Cuirass 目前僅支援 x86 架構,缺乏非 x86 構建能力
  • Codeberg 的儲存空間配額影響基於 fork 的工作流程

團隊提出的應對方案是強制推廣 AGit 工作流程,讓貢獻者直接推送至上游而非 fork,以降低每位用戶對 Codeberg 基礎設施的儲存壓力。

原始來源:GNU Guix Blog — One year with Codeberg · GCD 002 提案


GIMP 0.54.1 封裝成 Flatpak:1996 年的 Motif 版本在現代 Linux 重生

LWN.net · 2026-06-22

GNOME 貢獻者 balooii 將 GIMP 0.54.1(1996 年原版)成功封裝為可在現代 64 位元 Linux 系統上執行的 Flatpak。這個版本使用 Motif 工具組建構,正是 Larry Ewing 繪製 Tux 企鵝吉祥物時所用的版本,具有重要的歷史意義。

這次封裝的技術挑戰在於讓近三十年前的程式碼在現代沙盒化容器中正常運作,同時維持 Flatpak 的隔離語意。此次封裝雖不具備現代圖形編輯的實用性,但體現了 Flatpak 格式對長尾歷史軟體保存的潛力,也引發了社群對 Linux 圖形應用生態系歷史傳承的討論。

原始來源:LWN.net — GIMP 0.54.1 in a Flatpak


End of article
0
Would love your thoughts, please comment.x
()
x