▲

GN⁺: dockerc - Docker 이미지를 스탠드얼론 포터블 바이너리로 컴파일하는 도구

 (github.com/NilsIrl)
27P by neo 2달전 | favorite | 댓글 2개
  • 도커 이미지를 독립 실행형, 포터블한 바이너리로 컴파일하는 도구
  • 사용자들에게 docker run, pip install, npm i 등의 명령어 없이 실행 가능한 바이너리를 제공 가능

특징

  • 도커 이미지를 이식 가능한 바이너리로 컴파일.
  • 루트 권한이 필요 없는 컨테이너.
  • MacOS와 Windows 지원(QEMU 사용) : 예정
  • x86_64 지원 (arm64 지원 예정)
  • 인자 지원
  • -e를 사용하여 환경 변수 지정 지원.
  • -v를 사용하여 볼륨 지정 지원.

사용 방법

  • 최신 릴리스에서 dockerc 설치.
  • 도커 허브의 이미지 또는 로컬 도커 데몬 저장소의 이미지를 사용하여 출력 바이너리 생성.
  • 생성된 바이너리는 일반 바이너리처럼 호출 가능.
  • -e와 -v 옵션을 docker run 사용 시와 같은 방식으로 지정 가능.
  • 컨테이너 내에서 실행되는 네트워크 서비스에 직접 접근 가능, -p 지정 필요 없음.
  • 이미지 로딩에는 Skopeo 사용, 다른 위치에 대해서는 해당 문서 참조.

GN⁺의 의견

  • dockerc는 도커의 사용성을 크게 향상시킬 수 있는 도구로, 사용자가 복잡한 설치 과정 없이 애플리케이션을 실행할 수 있게 해줌. 이는 특히 비기술 사용자에게 매우 유용할 수 있음.
  • 도커 이미지를 바이너리로 컴파일하는 기능은 배포 및 배치를 단순화하며, 이는 개발자와 시스템 관리자에게 시간 절약과 효율성을 제공함.
  • 그러나 이 기술이 널리 채택되기 위해서는 보안, 성능 및 호환성과 관련된 문제들이 충분히 해결되어야 함. 예를 들어, 컴파일된 바이너리가 원본 도커 이미지만큼 안전한지, 모든 시스템에서 원활하게 작동하는지 등의 검증이 필요함.
  • 도커와 유사한 기능을 제공하는 다른 프로젝트로는 Podman이 있으며, 이는 루트 권한 없이 컨테이너를 실행할 수 있는 기능을 제공함.
  • dockerc를 도입할 때는 기존의 도커 워크플로우와의 통합, 이미지의 업데이트 및 관리 방법, 그리고 컴파일된 바이너리의 크기와 성능 등을 고려해야 함. 이 기술을 선택함으로써 얻을 수 있는 이점은 배포의 단순화와 사용의 용이성이지만, 반면에 컴파일 과정에서 발생할 수 있는 오버헤드와 잠재적인 호환성 문제를 신중히 고려해야 함.
▲
cosine20 2달전  [-]

오 꽤 흥미롭네요.

답변달기
▲
neo 2달전  [-]

Hacker News 의견

  • 이것은 정말 멋진 일임.

    • 사용자는 자신의 도커를 더 배포 가능하게 만들려고 노력 중임. 현재는 QEMU 컨테이너 안에 도커 컨테이너 안에 파이썬 환경에 있는 간단한 파이썬 스크립트로 클릭을 자동화하고 netcat을 사용하는 것임. 파일 크기가 20GB로 현대 기준으로 꽤 가벼움.

  • 과거에 나는 nix-bundle¹이나 그것의 공식 대응인 nix bundle²을 사용하고 추천했음.

    • 이 도구들은 도커 이미지를 직접 관리하는 단계를 건너뛸 수 있게 해줌. 특히 도커 이미지를 만드는 것이 어렵거나 그 과정이 잊혀진 예술인 경우에 편리함.
    • nix bundle은 뚱뚱한 실행 파일뿐만 아니라 도커 이미지, AppImages, 그리고 몇 가지 다른 형식의 이미지/실행 파일도 만들 수 있음.

  • 내장된 OS와 함께 휴대용 실행 파일로 돌아가는 것이 정말 좋음.

    • "내 컴퓨터에서는 작동한다"는 말을 새로운 수준의 문제 해결 지옥으로 끌어올림. 그럼에도 불구하고 프로젝트는 멋짐.

  • 사용자는 사람들이 이러한 것들을 실행하는 도커 컨테이너를 만들어낸 도커파일을 보내기 시작하는 것을 기다리고 있음.

  • 여기에는 어떤 위대한 우주적 아이러니가 있음.

    • 빌드하거나 설치할 필요 없이 실행 파일만 달라는 섹션 다음에는 이 프로젝트를 빌드하기 위한 zig의 주문이 바로 이어짐.

  • 이것은 멋진 진전임, Nils! AGI 하우스에서 대화한 이후 프로젝트의 진전을 보게 되어 기쁨.

    • dockerc는 Zig + crun + squashfs/overlayfs를 사용함. Nils(저자)가 이 스레드에서 더 많은 정보를 공유했음.

  • 여전히 다른 아키텍처에 대한 다른 것들이 필요함.

    • 이 시점에서는 정적으로 컴파일하고 가상 파일 시스템을 포함하는 것이 낫다고 생각함. 이것은 사실상 90년대에 Sun이 만든 것과 같음.

  • 좋은 아이디어! 이것은 실제로 어떻게 작동함?

    • 사용자는 이것이 사용자 정의 로더 + 도커 + 이미지를 실행 가능한 바이너리로 래핑하는 것이라고 추측함.

  • 랜트 그림을 사용한 것이 멋짐.

    • 다음 랜트 그림은 "실행 파일을 실행하면 해당 애플리케이션을 포함한 창이 열려야 한다"는 내용일 것임.

  • 이것은 무엇을 의미함? 사용자가 Ruby를 설치하지 않고도 휴대용 Ruby 실행 파일을 배포할 수 있게 됨?

답변달기