Apptainer（前身為 Singularity）已成為高效能運算（HPC）環境中受歡迎的容器解決方案。儘管該技術承諾提供安全、可攜式且易於使用的容器，但最近的社群討論揭露了使用者在實際部署中遇到的重大實務挑戰。
 |
|---|
| 一個有組織的介面展示 Terraform 容器結果，象徵著 HPC 環境中容器解決方案的更廣泛背景 |
容器隔離造成開發工作流程問題
Apptainer 容器的基本設計為開發團隊帶來了意想不到的障礙。使用者回報容器間的隔離使得建立模組化工作流程變得困難，特別是當不同工具需要協同工作時。當 Make、GCC 和 Git 等重要建置工具被放置在不同容器中時，它們無法有效地相互互動。這迫使團隊要麼將所有東西打包到龐大的單一容器中，要麼完全放棄容器化方法。
這個問題不僅限於簡單的工具互動。當應用程式在容器內編譯時，它們經常會對僅存在於該容器環境中的函式庫產生依賴性。這意味著程式在開發期間可能看起來運作正常，但在部署時會失敗，因為它們無法存取原始容器外的必要依賴項。
Apptainer 與其他容器解決方案比較
| 功能特色 | Apptainer | Docker/Podman | 傳統模組 |
|---|---|---|---|
| 需要 root 權限 | 否 | 否（無 root 模式） | 否 |
| 單一檔案分發 | 是（ SIF 格式） | 否（分層式） | 否 |
| 工具互動性 | 有限 | 有限 | 優秀 |
| HPC 叢集支援 | 優秀 | 有限 | 優秀 |
| 網路檔案系統相容性 | 優秀 | 差 | 優秀 |
| GPU 支援 | 原生支援 | 良好 | 不一定 |
HPC 環境儘管有限制仍推動採用
儘管面臨這些挑戰，Apptainer 在主要的 HPC 叢集中仍被廣泛使用，包括 Leonardo、LUMI、Fugaku 以及各大學運算中心。該技術在這些環境中的吸引力源於其無需 root 權限即可執行的能力，以及與共享運算資源的相容性。與 Docker 或 Podman 不同，Apptainer 容器可以完全存在於網路檔案系統上的使用者家目錄中，避免了對運算節點上通常有限的本地磁碟空間的需求。
「在運算節點上，/ 可能只有 500GB 的 nvme。這就是它擁有的全部磁碟空間。使用者透過 nfs 掛載他們的 $home 並獲得我們分配的任何配額。可能是數百 TB。」
這種架構差異在處理 HPC 環境中典型的規模時變得至關重要，因為將大型容器映像複製到數千個運算節點會造成重大的網路瓶頸和儲存挑戰。
使用 Apptainer/Singularity 的主要 HPC 叢集
- Leonardo (EuroHPC)
- LUMI (EuroHPC)
- Fugaku (日本)
- NeSI (紐西蘭)
- Levante (德國)
- 全球各大學計算中心
Apptainer 和 Singularity CE 之間出現技術差異
原始 Singularity 專案分裂後，容器生態系統變得更加複雜。Apptainer 代表在 Linux Foundation 下原始專案的延續，而 Sylabs 則將 Singularity CE 維護為獨立的分支。雖然兩個系統在很大程度上保持相容，但正在出現影響實際使用的細微差異。
最近發現的問題包括時區處理錯誤，這些錯誤影響其中一個實作但不影響另一個，為依賴精確時間計算的科學運算應用程式帶來潛在問題。這些分歧突顯了在相似但獨立的程式碼庫之間維持相容性的挑戰。
替代解決方案獲得關注
Apptainer 的實務困難促使一些組織探索替代方法。傳統的模組系統如 TCL（現在是 Lua）模組正在捲土重來，在不承受容器隔離懲罰的情況下，提供不同軟體元件之間更好的整合。這些系統允許混合搭配不同的工具和版本，同時維持可重現的環境。
其他團隊轉向較新的解決方案，如提供基於 Nix 的應用程式沙盒化的 Flox，或堅持使用無 root 權限的 Docker 和 Podman 配置，這些配置可以提供類似的安全優勢並具有更廣泛的生態系統支援。
Apptainer 持續面臨的挑戰反映了關於容器在科學運算環境中角色的更廣泛問題，在這些環境中，對可重現性的需求必須與複雜、相互連接的工作流程的實務要求之間取得平衡。