紅帽容器管理工具Podman 4.4合併Quadlet，簡化systemd容器管理

紅帽（Red Hat）在開源容器管理工具Podman 4.4版本合併了Quadlet，進一步消除在Linux系統與服務管理器systemd執行容器的複雜性，讓用戶能夠像是使用Kubernetes檔案，用宣告的方式定義要執行的內容。

Podman是Linux上無常駐程式的容器引擎，紅帽在RHEL 8.0的時候就已經不包含Docker，不少用戶轉而使用Podman，而紅帽提到，Podman好處之一是能夠與systemd協同運作，其使用標準的fork/exec模型，因此很適應systemd系統以及服務管理器模型。

而Quadlet原本是一個自選工具，能夠讓使用者以更好的方式，以程序管理器systemd執行Podman系統容器。之所以會有Quadlet這種工具的需求，是因為雖然容器通常在雲端環境運作，並且和Kubernetes等調度工具一起使用，主要用於開發和測試目的，因此用戶能夠手動管理容器。

但也有一小部分用例，需要自動容器管理，在較小的單節點上，像是嵌入式或是車用裝置，缺乏系統管理員、網路連線或是邊緣伺服器控制，因此便可以使用systemd調度容器，雖然有很多方法可以將podman和systemd結合使用，但是通常systemd配置檔案過大或是難以維護，因此在Podman整合Quadlet，便能讓用戶更簡單地使用systemd管理Podman容器。

Podman在4.3的時候，加入了自定義健康檢查操作功能，可以在容器發生問題時，自動採取諸如重新啟動等措施，而systemd與Podman的結合，使這項功能有更好的發揮，能夠自動更新和回退在systemd中執行的Kubernetes工作負載，用戶可仰賴systemd管理服務，監控工作負載的生命周期和服務狀態，在故障時重新啟動。

由於Podman和systemd單元檔案運作良好，解決了IT管理員許多麻煩事，用戶也開始向上游Podman專案提出最佳實踐的請求，希望能以systemd服務形式執行Podman，因此紅帽開始和systemd合作，針對最佳實踐制定了模板，在Podman新增podman generate systemd指令，可以直接從正在執行的容器，創建單元檔案。

之後才又進一步衍生出Quadlet專案，透過通用systemd單元檔案定義動態重新生成服務，紅帽解釋，Quadlet對用戶隱藏systemd執行容器的複雜性，即便從頭開始編寫單元檔案也變得容易，用戶可將其視為適用於systemd的Compose或Kubernetes檔案。用戶現在已經可以在CentOS Stream、Fedora等Linux發行版，用到已經整合Quadlet的Podman 4.4。