▲

Unregistry – “docker push”를 레지스트리 없이 서버에 직접 전송

 (github.com/psviderski)
2P by GN⁺ 7일전 | ★ favorite | 댓글 1개
  • Unregistry는 외부 레지스트리 없이 Docker 이미지를 원격 서버에 직접 전송할 수 있는 오픈소스 툴임
  • docker pussh 명령으로 SSH를 통해 원격 서버에 이미지를 효율적으로 전송하며, 이미 존재하는 레이어는 건너뜀
  • 전통적인 Docker Hub, 자체 레지스트리, save/load 방식의 복잡함과 비효율성을 해소함
  • 운영 환경 배포, CI/CD, 폐쇄망 환경 등에서 빠르고 안전한 이미지 이전이 큰 장점임
  • 설치, 사용, 요구 사항이 매우 단순하며, 추가 서비스 운영이나 포트 노출이 필요 없음

Unregistry 소개 및 주요 장점

  • Unregistry는 Docker 데몬의 스토리지에서 직접 이미지를 저장 및 제공하는 경량 이미지 레지스트리임
  • docker pussh 커맨드를 사용하면 SSH를 통해 외부 레지스트리 없이 이미지를 바로 원격 Docker 서버로 이동 가능함
  • 전송 시 이미 서버에 존재하는 레이어는 제외하고 필요한 부분만 빠르게 전송하는 효율성 제공함

기존 Docker 이미지 배포의 문제점

  • 이미지를 로컬에서 빌드한 후 서버로 전송할 때 선택지가 아래와 같음
    • Docker Hub/GitHub Container Registry: 코드가 외부에 공개되거나 개인 저장소 사용 시 비용 발생함
    • 자체 레지스트리: 별도 서비스 운영 및 보안, 스토리지 관리 부담 증가함
    • Save/Load: 전체 이미지를 항상 전송하여 비효율 발생함
    • 서버에서 직접 재빌드: 시간 및 서버 리소스 낭비와 디버깅 문제 발생함

Unregistry 솔루션

  • docker pussh myapp:latest user@server 명령 한 번으로 중간 저장소 없이 직접 전송 가능함

  • 추가적인 레지스트리 설정, 포트 노출, 스토리지 준비, 구독 필요 없음

  • 전송 과정

    • SSH 터널을 원격 서버로 연결함
    • 임시로 unregistry 컨테이너 실행함
    • 랜덤 로컬 포트와 unregistry 포트 연결함
    • docker push로 존재하지 않는 레이어만 전송함 (즉시 사용 가능)
    • unregistry 컨테이너와 SSH 터널 종료함

  • rsync처럼 단순·효율적 방식임

  • 본 프로젝트는 Uncloud에서 다중 Docker 호스트로 컨테이너를 배포하는 과정의 복잡함을 단순화하기 위해 개발됨

사용 예시

배포 환경으로 직접 이미지 전송

  • 로컬에서 빌드 후 직접 운영 서버로 push함
    • docker build --platform linux/amd64 -t myapp:1.2.3 .
    • docker pussh myapp:1.2.3 deploy@prod-server
    • ssh deploy@prod-server docker run -d myapp:1.2.3

CI/CD 파이프라인

  • 레지스트리 복잡성 없이 빌드 및 배포 지원
    • GitHub Action YAML 등에서 직접 전송 사용 가능

홈랩, 인터넷이 없는 폐쇄망 환경

  • 이미지 인터넷 공개 없이 격리 네트워크에 안전하게 전송함

사용 방법

  • SSH 사용자 계정이 원격에서 docker 명령을 사용할 수 있어야 함
  • SSH 프라이빗 키나 커스텀 SSH 포트 등 추가 옵션 지원함
  • 멀티 플랫폼 이미지 전송도 지원 (containerd 기반일 경우)

요구 사항

로컬 환경

  • Docker CLI (플러그인 지원, 19.03+)
  • OpenSSH 클라이언트

원격 서버

  • Docker가 설치 및 실행 중이어야 함
  • ssh 사용자가 docker 권한을 소유해야 하며, 필요 시 패스워드 없는 sudo docker 실행 가능해야 함
  • containerd image store 사용 시 성능이 향상됨
    • /etc/docker/daemon.json에 다음 설정 추가 및 docker 재시작 필요 
      {
  "features": {
    "containerd-snapshotter": true
  }
}

고급 사용법

로컬 독립형 레지스트리로 사용

  • 추가 컴포넌트 없이 unregistry를 로컬 레지스트리로 손쉽게 운영 가능함
  • 도커 명령으로 deploy 및 push 가능

SSH 커스텀 옵션 활용

  • SSH config 파일을 활용해 추가 인증, 포트 등 조건에 맞는 세부 설정 가능

기여 및 커뮤니티

  • 버그 발견 시 GitHub 이슈 등록 활용
  • Uncloud Discord 커뮤니티에서 피처·로드맵·구현 세부 논의 가능

영감과 참고 오픈소스

  • Spegel: containerd 기반의 P2P 컨테이너 이미지 레지스트리 구현에서 영감 받음
  • Docker Distribution: 실제 레지스트리 구현 베이스로 사용됨

요약

  • Unregistry는 Docker 이미지를 쉽고 빠르게 원격 서버로 직접 이전할 수 있는 툴로 레지스트리 구축 및 관리 부담을 없앰
  • 운영 환경 배포, CI/CD, 폐쇄망 등 다양한 시나리오에서 강력한 이점을 제공함
  • 서버와 관리자가 단순하게 이미지만 절차 없이 이동하고 싶은 경우 매우 적합함
▲
GN⁺ 7일전  [-]
Hacker News 의견

  • 서버의 특성과 보안 경계, 하드닝 측면에서 Homebrew를 Linux에서 쓰는 것을 권장하고 싶지 않음, Linux용 설치가 마치 사후 처리처럼 제공됨에도 불구하고 패키지 매니저라기보다는 바둑판 위의 비둘기처럼 동작하는 모습임

  • 시스템에서 Ansible 같은 푸시 배포 툴링을 이미 사용하는 곳에 잘 어울릴 만한 멋진 아이디어라는 생각임, 또 Docker 레지스트리가 24시간 지원되지 않는 기업에는 핫픽스 배포 기법으로도 적합함을 느낌, OCI 툴링(buildah 등)과도 깔끔하게 연동되는지, 아니면 양쪽 모두에 Docker 전체 설치가 필요한지 궁금한 상황임, 아직 본격적으로 파보진 않았으나 이와 관련된 작업 예정이고, skopeo가 이러한 환경에서 작동하려면 원격 서버에서 자체 레지스트리를 부트스트랩 할 수 있는 기능이 부족하다고 느꼈음

    • 원격 서버에는 containerd가 필요하고(Docker와 Kubernetes도 containerd 사용), 클라이언트 쪽에는 레지스트리 API를 이해하는 어떤 것이든 가능(OCI Distribution spec: https://github.com/opencontainers/distribution-spec), Unregistry가 공식 Docker registry 코드를 API 계층으로 재사용해서 Docker Hub의 registry와 유사한 느낌임, skopeo, crane, regclient, BuildKit 등 OCI registry를 사용할 수 있으며, 이들을 쓰려면 원격 호스트에서 unregistry 직접 실행이 필요함, 'docker pussh' 명령어는 로컬 Docker를 활용해 이 모든 흐름을 자동화해주는 역할임, bash 스크립트로 되어 있으니 한 번 확인 권장 https://github.com/psviderski/unregistry/blob/main/docker-pussh, 직접 마음대로 수정도 쉬움

    • 양쪽에 docker daemon이 필요함, 이 방법은 두 데몬 사이에 layer를 ssh로 공유한다는 영리한 방식을 사용함

  • pussh 명령어가 기억하기 쉽고 자기설명적이며, 기존 표준 명령어와 한 글자 차이만 나는 멋진 언어유희를 보여준다고 생각함

    • "pussh"도 괜찮지만, 자동화에선 "docker push-over-ssh" 같은 좀 더 명확한 별칭이 좋을 것 같다는 의견임, "pussh"를 처음 보는 사람이 오타로 오해할 수 있고 불필요한 혼란이 생길 수 있음, 짧은 버전과 전체 플래그 버전 모두 지원하면 좋다고 봄

    • 's' 하나를 더 쓴 이유가 'sssh'를 나타내려는 것인지 농담 섞인 설명이 있음, 어떤 이는 단순 오타라고 함

    • 'pussh'라는 이름이 다른 명령어와 충돌 가능성이 있음

  • 이런 기능은 예전부터 있었어야 했고 매우 멋지다고 생각함, Docker registry는 그 자체로 가치가 있지만 전반적으로 너무 복잡해지고 해커 마인드와는 거리가 멀어졌다는 생각임

    • Docker가 VC 투자를 받았던 회사인 만큼, 어떻게든 수익을 내야 했던 상황임

  • 프로젝트와 접근법이 인상적임, 비싼 레지스트리에 질려서 Zot(https://zotregistry.dev) 같은 걸 직접 호스팅해봤으나 이 방법이 어떤 사용례에선 훨씬 간단해 보인다는 의견임, 쉽고 저렴하며 사용량기반인 프라이빗 레지스트리 서비스가 좀 더 보편화되었으면 하는 바람임

    • zothub.io SSL 인증서가 만료되었음을 알려주는 의견

  • Docker가 처음부터 이렇게 작동했어야 한다고 생각함, 멋진 아이디어라고 느낌

    • 이미지 파일을 아카이브로 저장해서 서버로 전송 후 로드하는 방법으로도 유사한 결과 가능함, 예를 들어 docker save -o my-app.tar my-app:latest로 저장, docker load -i /path/to/my-app.tar로 불러오기, ansible 같이 자동화 툴과 조합하면 Unregistry가 자동화하는 것을 직접 할 수 있음, 다만 save/load 방식은 전체 이미지를 모두 전송해야 하고, 이미지 관리도 아카이브 파일보다 더 편리하다는 단점이 있다고 github repo에서 밝힘

  • 이런 도구와 SSH 툴링을 활용한 셀프호스팅으로의 회귀가 반갑고, 잘 만든 결과물이라 생각함, 직접 사용해 볼 계획임

  • 이 도구 덕분에 uncloud라는 프로젝트를 처음 알게 되었고 내가 원하던 dokku 같은데 더 강력한 서버 배포 솔루션처럼 보여 흥미롭다는 생각임

    • uncloud가 자신에게 잘 맞는다는 피드백에 공감함, 궁금한 점 있으면 Discord로 문의 환영

    • https://skateco.github.io/라는 유사한 접근의 서비스도 있으니 참고 추천

    • Portainer 추천, 포테이너 커뮤니티 에디션과 포테이너 에이전트를 사용해 AWS EC2 두 대에서 잘 운용 중임, 스택 기능(docker compose 기반)이 특히 강점이고, 하나의 EC2에서 portainer agent가 컨테이너로 Caddy를 운영하며 로드밸런서와 리버스 프록시 기능을 수행함

  • 참신한 아이디어임, 다만 이런 방식이 서비스 배포와 강하게 결합되어 배포 및 확장, 예를 들어 레드/그린 배포 시 "푸시"를 인지하는 추가 로직이 필요함, 생각해보니 이런 역할이 uncloud에서 구현된 구조임을 알게 됨, 하지만 결국 트레이드오프이고, 한 대의 Hetzner VM에 단순함을 중시한다면 로컬에서 이미지 빌드만으로도 충분히 만족할 수 있는 선택임

    • 역시 모든 것에는 트레이드오프가 있고 상황에 맞는 최적의 도구를 선택할 수 있다는 점이 최고라는 의견임
답변달기