▲

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

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

  • 우리 팀은 실리콘 디자인/검증용 컴퓨트 클러스터에서 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
    • Apptainer는 옛 Singularity 프로젝트의 포크가 아님. Apptainer가 원래의 본 프로젝트고, 커뮤니티 투표로 이름만 변경됨. Linux Foundation 소속으로 넘어감
      • Sylabs가 원래 개발자를 영입해서 프로젝트를 포크한 사례가 singularity ce임
      • 참고: community announcement
    • 그래도 상호 컨테이너 호환성은 유지되어, Apptainer에서 빌드해도 Singularity에서 실행 가능함 (그 반대도 마찬가지)

  • Apptainer는 곧 Singularity임. 관련 논문은 여기

    • 대학이나 정부 클러스터에서 공유 시스템을 쓸 경우, Apptainer는 항상 있지만 Podman/Docker는 거의 없음
    • 이런 환경에서는 컨테이너 사용 대신, 시스템 관리자와 친해져서 해당 클러스터의 운영 방식을 이해하는 것이 더 유리함
    • 왜 Docker/Podman은 덜 쓰이나, 그리고 왜 컨테이너 사용을 피하는 것이 좋은지 궁금함. 혹시 성능 문제가 이유인가

  • Flatpak이 OSTree에서 컨테이너 기반으로 전환하려 함. 유지 보수되는 컨테이너 툴링이 큰 장점이라고 함. 그런데 이게 Apptainer와 어떻게 다를까 궁금함

    • 아마도 Flatpak이 xdg-dbus를 통한 퍼미션 세분화 등 개별 앱 샌드박스 제어를 해서 네이티브처럼 쓸 수 있게 하는 것이 특징임
      • Apptainer는 이 정도로 완전히 분리/격리되는지 확실치는 않음
      • containertoolbx 같은 툴을 활용하면 컨테이너 방식 차이가 별로 의미없어짐
      • 솔직히 툴끼리의 기능 겹침이 많지만, 이 자체도 괜찮다고 생각함

  • 내가 사용하는 환경에서 Apptainer 사용의 최대 목적은 배포, 격리, 소프트웨어 가용성과 관련 없음.

    • 우리 HPC 클러스터는 각 사용자마다 inode 쿼터 제한이 있는데, 그 때문에 파일이 아주 많은 소프트웨어(예: Anaconda) 설치가 힘듦
    • 하지만 Apptainer 이미지는 squashfs 기반 단일 파일이라 인도 쿼터 걱정 없이 여러 개를 둘 수 있음
    • 동일한 소프트웨어를 일반적으로 설치하는 게 더 쉽긴 하지만, 쿼터는 순식간에 소진됨

  • Havoc 의견에 공감함. 애매한 메시지임: Apptainer가 Desktop용 Flatpak 대체품인가, 아니면 서버 목적용인가 헛갈림

    • 서버용임. 그러나 질문 자체가 애매함
      • Apptainer는 고정(immutable), rootless 컨테이너에서 CLI 앱 실행용임
      • 가장 비슷한 툴은 Fedora Toolbx임
      • Apptainer 주 용도는 과학 컴퓨팅 툴 배포와 재사용. root 권한 없이 사용하고, rootfs를 컨테이너마다 변경 불가하고, 자동으로 작업 디렉토리 마운트, GPU도 잘 지원함(이건 직접 테스트X)
      • 참고: Fedora Toolbx

  • "Apptainer"라는 이름은 발음이 어색하고 뭔가 올바르지 않은 느낌임

  • 개발자라면 격리용 컨테이너 도구를 찾고 있을 수 있음

    • 나는 Podman 기반으로 각기 다른 개발 프로젝트를 격리하는 도구를 만들어봄. 보안 테스트나 사용에 필요하다면 코드 또는 블로그 글에서 확인 가능함
    • 왜 toolbox로 충분하지 않았는지 궁금함
      • 나는 toolbox가 프로젝트별로 개발 환경을 설치할 때 여러 숨겨진 파일시스템을 관리할 필요가 없어서 괜찮았음

  • SLURM 클러스터, 루트 권한 없는 서버에서는 매우 유용함

    • 나도 SLURM 클러스터에서 사용해 본 경험 있음
      • 공식 문서가 잘되어 있어서 입문용으로 충분함
      • 다만 fakeroot나 sudo가 없으면 로컬에서 Apptainer를 빌드하여 서버로 직접 전송해야 하는 번거로움이 있었음
답변달기