서버의 특성과 보안 경계, 하드닝 측면에서 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로 문의 환영
Portainer 추천, 포테이너 커뮤니티 에디션과 포테이너 에이전트를 사용해 AWS EC2 두 대에서 잘 운용 중임, 스택 기능(docker compose 기반)이 특히 강점이고, 하나의 EC2에서 portainer agent가 컨테이너로 Caddy를 운영하며 로드밸런서와 리버스 프록시 기능을 수행함
참신한 아이디어임, 다만 이런 방식이 서비스 배포와 강하게 결합되어 배포 및 확장, 예를 들어 레드/그린 배포 시 "푸시"를 인지하는 추가 로직이 필요함, 생각해보니 이런 역할이 uncloud에서 구현된 구조임을 알게 됨, 하지만 결국 트레이드오프이고, 한 대의 Hetzner VM에 단순함을 중시한다면 로컬에서 이미지 빌드만으로도 충분히 만족할 수 있는 선택임
역시 모든 것에는 트레이드오프가 있고 상황에 맞는 최적의 도구를 선택할 수 있다는 점이 최고라는 의견임
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는 그 자체로 가치가 있지만 전반적으로 너무 복잡해지고 해커 마인드와는 거리가 멀어졌다는 생각임
프로젝트와 접근법이 인상적임, 비싼 레지스트리에 질려서 Zot(https://zotregistry.dev) 같은 걸 직접 호스팅해봤으나 이 방법이 어떤 사용례에선 훨씬 간단해 보인다는 의견임, 쉽고 저렴하며 사용량기반인 프라이빗 레지스트리 서비스가 좀 더 보편화되었으면 하는 바람임
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에 단순함을 중시한다면 로컬에서 이미지 빌드만으로도 충분히 만족할 수 있는 선택임