# Apptainer - 리눅스용 어플리케이션 컨테이너

> Clean Markdown view of GeekNews topic #21667. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=21667](https://news.hada.io/topic?id=21667)
- GeekNews Markdown: [https://news.hada.io/topic/21667.md](https://news.hada.io/topic/21667.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-06-27T09:31:02+09:00
- Updated: 2025-06-27T09:31:02+09:00
- Original source: [github.com/apptainer](https://github.com/apptainer/apptainer)
- Points: 14
- Comments: 2

## Summary

Apptainer는 **단순함/속도/보안**을 중심으로 설계된 **오픈소스 컨테이너 플랫폼**입니다. **불변 단일 파일 컨테이너 이미지 포맷**, 그리고 **암호화 및 서명** 기능을 지원합니다.

## Topic Body

- 단순함/속도/보안을 중심으로 설계된 **오픈소스 컨테이너 플랫폼**  
  - **HPC(고성능 컴퓨팅)** 와 **공유 시스템** 환경에 최적화됨  
- **불변(Immutable) 단일 파일 컨테이너 이미지 포맷**을 제공하며, **암호화 및 서명** 지원  
- 격리보다는 **통합 사용성**에 집중해, 클러스터/서버 환경에서 GPU, 고속 네트워크, 병렬 파일 시스템을 바로 활용할 수 있음  
- OCI(Open Containers Initiative) 레지스트리에서 모든 컨테이너를 가져올 수 있으며, **Docker와 호환성을 극대화**   
  - Docker Hub에 있는 대부분의 컨테이너를 변경 없이 풀(pull), 실행(run), 빌드(build)할 수 있도록 지원  
- 기존 **Singularity**에서 이름을 변경해 **Linux Foundation** 프로젝트로 이관됨   
- **SIF(Singularity Image Format)** 기반의 단일 파일 컨테이너로 손쉽게 이동, 배포 및 공유 가능  
- 컨테이너 내부와 외부의 사용자 권한이 동일하며, 기본적으로 호스트에서 추가 권한 상승 불가한 **안전한 보안 모델** 적용  
- BSD 라이선스

## Comments



### Comment 40682

- Author: galadbran
- Created: 2025-06-27T10:42:11+09:00
- Points: 1

Hacker News 의견 에서 언급되는 unregistry 기사:  
[Unregistry – “docker push”를 레지스트리 없이 서버에 직접 전송 | GeekNews](https://news.hada.io/topic?id=21538)

### Comment 40674

- Author: neo
- Created: 2025-06-27T10:21:28+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=44385742)   
- 우리 팀은 실리콘 디자인/검증용 컴퓨트 클러스터에서 **Apptainer**를 시도해봤음, 하지만 최종적으로는 전통적인 **TCL(Lua로 전환)** 모듈로 돌아감  
  - 여러 문제점을 겪었음.  
    - 첫째, 컨테이너끼리 서로를 사용할 수 없음. 예를 들어 **Make, GCC, Git** 같은 도구가 각각 다른 Apptainer에 있으면, Make 안에 들어가면 GCC를 못 보는 상황 발생  
    - 둘째, 컨테이너 내부에 의존하는 산출물이 있으면 제대로 동작하지 않음. GCC Apptainer로 프로그램 빌드 시 빌드된 바이너리가 Apptainer 내부 라이브러리에 연결되어 실행이 안 됨, **C 헤더 문제**도 발생  
    - 셋째, PATH 값이 계속 꼬여서, Apptainer 외부의 필요한 경로나 도구를 못 보게 되는 문제 반복  
    - 전체적으로 아이디어는 좋았으나 **실제 사용성**에서는 번거로움만 심해서 결국 **옛날 OS(RHEL8)** 를 직접 사용하는 게 훨씬 수월했음  
  - 나는 Apptainer/Singularity를 **Docker**와 비슷하게 생각함(단, 네트워킹 설정은 풀로 없음). 이런 문제는 전통적인 Docker 컨테이너에서도 동일하게 발생함.  
    - 나의 HPC 워크플로에서는 Apptainer를 Docker의 드롭인 대체품처럼 쓰고, 이런 용도엔 잘 맞음  
    - Apptainer의 가장 큰 장점은 **Non-root권한 컨테이너**라는 점임. 덕분에 복잡한 네트워킹을 못하긴 하지만, HPC 같은 **멀티테넌트 환경**에서 훨씬 **보안적**임  
  - 컨테이너 앱을 쓰면서 가장 큰 불만이 **컨테이너답게 동작한다**는 거라면, 그건 컨테이너의 본질임  
  - 컨테이너 조각들을 섞어 쓰면 안 됨. 마치 서로 다른 리눅스 배포판의 바이너리를 섞어 쓰지 않는 것과 같음  
      - 컨테이너는 하나의 통합 환경에서 개발에 활용하는 게 이상적임. 컨테이너는 **격리된 환경**이기 때문에, 어떤 것을 컴파일해도 결과물은 자기 컨테이너에 있어야 함  
      - 단, 동일한 **베이스 이미지**를 여러 개 생성해서 파일 호환성을 확보하는 방법도 가능함(필요한 모든 **의존성**을 포함시킬 때만)  
- Apptainer가 주목받는 것이 반가움. 일부 상황에서는 **Docker, Podman** 등보다 뛰어남  
  - **여러 작업을 한 컨테이너에서 실행**해야 할 때(이건 다른 컨테이너 기술에서는 권장X)  
  - **HPC** (그리고 일부 대학 환경)  
  - **단일파일 배포 모델** 지원(물론 델타는 미지원)  
  - 별도의 외부 서버 없이 **SIF 파일 암호화 서명 가능**  
  - **강력한 GPU 지원**  
- docker도 `docker save`와 `docker load` 명령어로 **단일 파일 배포**가 가능함.  
  - 델타를 지원하진 않지만, 최근 "unregistry"라는 솔루션이 HN에 링크되었는데 이는 **Docker Registry 없이**도 "docker push" 기능과 **델타 반영**이 가능함  
- Apptainer 및 **singularity ce** 모두 HPC에서 흔히 사용됨. 두 제품 모두 **옛날 Singularity 프로젝트**에서 분기됐지만 완전히 똑같진 않음  
  - 우리는 여러 슈퍼컴퓨터(HPC)에서 singularity를 쓰고, 일부 연구자들은 로컬에 Apptainer를 설치해 사용함  
  - 최근 Python 코드(matplotlib, xarray 등)에서 **타임존 버그**를 발견했는데, singularity ce에선 문제가 있었으나 Apptainer에서는 제대로 동작했음  
  - 신규 Apptainer는 코드 베이스가 비슷하지만, 버그 수정이 더 빠르게 반영되고 있음. 예시로, singularity는 **사용자 타임존**을 시스템에 덮어써서 문제가 발생했음  
  - 참고 링크: [singularity 이슈 #3686](https://github.com/sylabs/singularity/issues/3686)  
  
  * Apptainer는 옛 Singularity 프로젝트의 **포크**가 아님. Apptainer가 원래의 본 프로젝트고, 커뮤니티 투표로 이름만 변경됨. Linux Foundation 소속으로 넘어감  
    - Sylabs가 원래 개발자를 영입해서 프로젝트를 포크한 사례가 singularity ce임  
    - 참고: [community announcement](https://apptainer.org/news/community-announcement-20211130/)  
  
  - 그래도 상호 **컨테이너 호환성**은 유지되어, Apptainer에서 빌드해도 Singularity에서 실행 가능함 (그 반대도 마찬가지)  
  
- Apptainer는 곧 Singularity임. 관련 논문은 [여기](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177459)  
    - 대학이나 정부 클러스터에서 공유 시스템을 쓸 경우, **Apptainer**는 항상 있지만 Podman/Docker는 거의 없음  
    - 이런 환경에서는 컨테이너 사용 대신, **시스템 관리자**와 친해져서 해당 클러스터의 운영 방식을 이해하는 것이 더 유리함  
    - 왜 Docker/Podman은 덜 쓰이나, 그리고 왜 컨테이너 사용을 피하는 것이 좋은지 궁금함. 혹시 **성능** 문제가 이유인가  
  
- Flatpak이 **OSTree**에서 컨테이너 기반으로 전환하려 함. 유지 보수되는 컨테이너 툴링이 큰 장점이라고 함. 그런데 이게 Apptainer와 어떻게 다를까 궁금함  
  - 아마도 Flatpak이 **xdg-dbus**를 통한 **퍼미션 세분화** 등 개별 **앱 샌드박스 제어**를 해서 네이티브처럼 쓸 수 있게 하는 것이 특징임  
    - Apptainer는 이 정도로 완전히 분리/격리되는지 확실치는 않음  
    - [containertoolbx](https://containertoolbx.org/) 같은 툴을 활용하면 컨테이너 방식 차이가 별로 의미없어짐  
    - 솔직히 **툴끼리의 기능 겹침**이 많지만, 이 자체도 괜찮다고 생각함  
  
- 내가 사용하는 환경에서 **Apptainer 사용의 최대 목적**은 배포, 격리, 소프트웨어 가용성과 관련 없음.  
  - 우리 HPC 클러스터는 각 사용자마다 **inode 쿼터 제한**이 있는데, 그 때문에 파일이 아주 많은 소프트웨어(예: Anaconda) 설치가 힘듦  
  - 하지만 Apptainer 이미지는 **squashfs 기반 단일 파일**이라 인도 쿼터 걱정 없이 여러 개를 둘 수 있음  
  - 동일한 소프트웨어를 일반적으로 설치하는 게 더 쉽긴 하지만, 쿼터는 순식간에 소진됨  
  
- Havoc 의견에 공감함. 애매한 메시지임: Apptainer가 Desktop용 Flatpak 대체품인가, 아니면 서버 목적용인가 헛갈림  
  - 서버용임. 그러나 질문 자체가 애매함  
    - Apptainer는 **고정(immutable), rootless 컨테이너에서 CLI 앱 실행**용임  
    - 가장 비슷한 툴은 Fedora Toolbx임  
    - Apptainer 주 용도는 **과학 컴퓨팅 툴 배포와 재사용**. root 권한 없이 사용하고, rootfs를 컨테이너마다 변경 불가하고, 자동으로 작업 디렉토리 마운트, GPU도 잘 지원함(이건 직접 테스트X)  
    - 참고: [Fedora Toolbx](https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/)  
  
- "Apptainer"라는 이름은 **발음이 어색**하고 뭔가 올바르지 않은 느낌임  
  
- 개발자라면 **격리용 컨테이너 도구**를 찾고 있을 수 있음  
  - 나는 Podman 기반으로 각기 다른 개발 프로젝트를 격리하는 도구를 만들어봄. 보안 테스트나 사용에 필요하다면 [코드](https://github.com/evertheylen/probox) 또는 [블로그 글](https://evertheylen.eu/p/probox-intro/)에서 확인 가능함  
  - 왜 toolbox로 충분하지 않았는지 궁금함  
    - 나는 toolbox가 프로젝트별로 개발 환경을 설치할 때 여러 숨겨진 파일시스템을 관리할 필요가 없어서 괜찮았음  
  
- SLURM 클러스터, 루트 권한 없는 서버에서는 매우 유용함  
  - 나도 SLURM 클러스터에서 사용해 본 경험 있음  
    - 공식 **문서가 잘되어 있어서 입문용으로 충분**함  
    - 다만 fakeroot나 sudo가 없으면 로컬에서 Apptainer를 빌드하여 서버로 직접 **전송**해야 하는 번거로움이 있었음