▲

Uncloud - Kubernetes의 복잡함 없이 서버 간 컨테이너 앱을 배포하는 도구

(uncloud.run)
1P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • Uncloud는 Kubernetes 없이도 여러 서버에 컨테이너화된 웹 애플리케이션을 배포하고 확장할 수 있는 오픈소스 도구
  • Docker Compose 기반 워크플로우를 유지하면서, 무중단 배포·자동 HTTPS·서버 간 스케일링을 지원
  • 중앙 제어 플레인 없이 각 머신이 WireGuard 기반 P2P 네트워크로 연결되어, 일부 서버가 오프라인이어도 클러스터 운영 유지
  • Caddy 리버스 프록시를 통한 자동 HTTPS, 내장 DNS 기반 서비스 디스커버리, 로드밸런싱 기능 포함
  • 클라우드·온프레미스 혼합 환경에서도 동일한 방식으로 배포 가능해, 인프라 제어권과 비용 예측성을 확보

PaaS 유사 워크플로우

  • Heroku나 Fly.io처럼 간단한 배포 경험을 제공하면서도 서버와 데이터에 대한 완전한 제어권 유지
    • 요청 단위 과금이 아닌 예측 가능한 비용 구조
    • 벤더 종속성 없음, 표준 SSH 도구로 디버깅 가능
  • Docker Compose 친화적 구조로, 빌드·푸시·배포를 한 명령으로 수행
    • 이미지 레지스트리 불필요, 무중단 롤링 배포 지원
    • 여러 머신에 걸친 복제 스케일링 가능

저유지보수형 설계

  • 컨트롤 플레인이나 쿼럼 관리 불필요, 관리 복잡도 최소화
  • 포트 개방 없이 안전한 머신 간 통신 지원
  • 자동 서비스 탐색과 Let's Encrypt 기반 HTTPS 자동 발급 기능 내장

작동 방식

  • 복잡한 클러스터 대신 간단한 머신 네트워크로 구성, 유지보수 부담 없이 안정적 인프라 제공
  • 각 머신은 WireGuard 메시 네트워크에 참여해 자동 피어 탐색 및 NAT 트래버설 수행
    • 컨테이너는 고유 IP를 받아 서버 간 직접 통신 가능
  • 완전 분산형 구조로, 중앙 제어 노드 없이 각 머신이 클러스터 상태를 동기화
    • 일부 머신이 오프라인이어도 클러스터 운영 지속
  • Docker 유사 CLI로 전체 인프라 제어
    • 단일 머신 SSH 접근만으로 배포·모니터링·스케일링 수행 가능

주요 기능

  • 어디서나 배포 가능: 클라우드 VM, 전용 서버, 온프레미스 등 모든 Linux 머신 지원
  • 자동 HTTPS: 내장 Caddy 리버스 프록시로 무설정 TLS 인증서 발급 및 HTTPS 활성화
  • 로드밸런싱: 여러 머신에 분산된 컨테이너 복제본 간 트래픽 분배
  • 서비스 디스커버리: 내장 DNS가 네트워크 내 서비스 위치를 자동 추적
  • Infrastructure as Code: 기존 Docker Compose 파일로 전체 앱 스택 정의 가능
  • 벤더 종속성 없음: 클라우드와 자체 하드웨어를 자유롭게 혼합 사용 가능
▲
GN⁺ 6시간전  [-]
Hacker News 의견

  • 안녕하세요, 제작자임. 공유해줘서 고마움
    Uncloud는 컨트롤 플레인이 없는 컨테이너 오케스트레이터임. 쉽게 말해, 여러 머신에 걸친 Docker Compose에 자동 WireGuard 메시, 서비스 디스커버리, Caddy를 통한 HTTPS가 붙은 형태임. 각 머신은 Fly.io의 Corrosion을 이용해 클러스터 상태를 p2p 동기화함으로써 쿼럼 유지가 필요 없음
    Kubernetes를 스타트업과 유니콘 기업 양쪽에서 운영해온 경험 끝에, 대부분의 팀이 사실은 단지 몇 대의 머신에서 컨테이너를 잘 돌리고 네트워킹과 롤아웃, HTTPS만 필요하다는 걸 깨달았음. K8s의 운영 오버헤드는 그에 비해 너무 큼
    주요 특징은 다음과 같음

    • 익숙한 Docker Compose 스펙 사용, 새로운 DSL 학습 불필요
    • 외부 레지스트리 없이 직접 머신에 Docker 이미지를 빌드·푸시 (내 다른 프로젝트 unregistry 사용)
    • 선언적이 아닌 명령형 CLI 제공으로 디버깅이 쉬움
    • 클라우드 VM, 베어메탈, NAT 뒤의 Raspberry Pi까지 연결 가능
    • 메모리 사용량 150MB 미만
      프로젝트 링크: https://github.com/psviderski/uncloud
      • K8s는 이미 소규모 환경에서도 컨테이너를 잘 돌릴 수 있어서, 굳이 다른 걸 쓸 이유가 없다고 생각함. k3s 같은 경량 배포도 쉬워졌기 때문에 대안이 필요하다고 느끼지 않음
      • 아이디어는 멋지지만 uc machine init이 내부적으로 root 권한으로 curl | bash를 실행하는 방식은 보안상 위험해 보임. 테스트는 해보고 싶지만 실제 머신에서는 돌리지 않을 것 같음
      • 정말 흥미로움. 곧 시도해볼 기회가 있을 듯함. 다만 문서를 봐도 클러스터 설정 후 다른 엔지니어를 온보딩하는 방법이나 CI/CD 러너에서 배포하는 방식이 명확하지 않음. 새 머신에서 기존 클러스터에 연결하는 절차가 궁금함
      • Kamal과의 차이점이 궁금함
      • WireGuard로 구성된 프라이빗 네트워크 내에서 AWS RDS 같은 외부 서비스에 보안 연결을 어떻게 하는지 궁금함. Tailscale의 AWS RDS 접근 방식처럼 지원되는지 알고 싶음

  • 커리어 대부분을 Kubernetes로 보냈는데, 컨트롤 플레인이 없는 구조의 장점이 무엇인지 궁금함. 내게는 컨트롤 플레인이야말로 K8s의 핵심 기능임.
    수백 노드, 만여 개 컨테이너 정도는 관리형 클러스터로 자동 업데이트되기 때문에 큰 부담이 없음. 사람들이 직접 K8s를 셀프호스팅하면서 겪는 고통이 이런 대안의 배경인지 궁금함

    • “수백 노드, 만 개 컨테이너”가 작다고 느껴지지 않음. 나는 2~5대 노드, 10~30개 컨테이너 정도의 규모인데, 이 정도면 K8s는 너무 무거움. 이런 소규모 기업이 많을 것 같음
    • 무례한 질문 아님. 컨트롤 플레인이 없는 장점은 모든 머신이 동등한 피어 구조로 단순화된다는 점임. 중앙 집중식 “클러스터 브레인”이 없으니 HA 구성이나 etcd 쿼럼 문제를 걱정할 필요 없음.
      네트워크가 분할되어도 각 파티션이 독립적으로 동작 가능함. 예전 Chef나 Ansible 시절의 단순함에 K8s의 교훈을 더한 형태임
    • 물론 사람들이 셀프호스팅 K8s를 시도함. 백업처럼, 미리 해보지 않으면 필요할 때 못 하게 됨
    • 중소기업 입장에서는 만 개 컨테이너는 결코 작지 않음. 나는 10개 미만이지만 고가용성(HA) 이 필요함. Uncloud는 내 상황에 잘 맞을 듯함
    • “만 개 컨테이너가 작다니, 그건 CI 잡 수치 아님? ;)”

  • 프로젝트가 멋짐. 나중에 꼭 써볼 생각임.
    더 단순한 대안을 찾는다면 Kamal도 괜찮음. 이건 K8s와 클라우드를 완전히 벗어난 회사가 직접 운영하며 실전 검증된 툴임

  • 서버를 지정했을 때 보안 강화(server hardening) 를 자동으로 해주는 기능이 있는지 궁금함

  • 나는 Docker Swarm 사용자임. Uncloud는 처음으로 흥미롭게 느껴지는 대안임
    궁금한 점은 다음과 같음

    • secrets 지원 계획이 있는지
    • Swarm+Traefik처럼 컨테이너 라벨로 URL rewrite 규칙을 정의할 수 있는지
    • 두 개의 Compose 스택을 배포했을 때, 서로 다른 스택의 컨테이너 간 네트워크 접근이 가능한지
    • 도메인과 내부 포트 매핑은 Compose 파일에서 x-ports: app.example.com:8000/https로 정의함.
      또는 x-caddy: Caddyfile로 Caddy 설정을 커스터마이징 가능함. 자세한 내용은 공식 문서 참고
      현재는 스택 간 네트워크 격리 기능이 없음. 관련 논의는 GitHub Discussion #94에서 진행 중임.
      어떤 동작을 기대하는지 궁금함
    • secrets 기능은 이슈 #75에서 트래킹 중임. Compose config로 주입은 가능하지만 암호화 저장은 아직 없음.
      2, 3번 질문의 답은 “아직은 아니고”, “현재는 예”임. 관련 논의는 Discussion #94 참고
      Swarm을 써본 입장에서, Swarm이 부족하거나 불편했던 점 중 Uncloud가 개선할 수 있을 부분이 무엇인지 궁금함

  • 정말 멋진 프로젝트임. 비슷한 주제의 다른 툴들도 참고할 만함

    • Dokploy
    • Coolify
    • Kubero
      더 알고 있다면 추가해줬으면 함
    • Self-hosted PaaS 리스트가 유용함.
      최근 Coolify를 써봤는데 다소 미완성 느낌이었음. 현재는 Dokku를 쓰고 있지만, DB 관리용 UI가 더 나아졌으면 함

  • 나는 k3s에 만족하지만, Docker Compose와 완전한 K8s 사이의 중간 지대에서 새로운 시도가 나오는 게 반가움. 특히 WireGuard 통합이 흥미로움

  • 정말 멋진 툴임. 수고에 감사함.
    백엔드의 상태 복제(state replication) 가 어떻게 동작하는지 궁금함. CRDT와 gossip 프로토콜을 언급했지만 구체적인 구현이 모호함

    • 현재 상태 복제는 Corrosion을 기반으로 함

  • K8s가 아니라면 왜 Nomad가 아닌가?

    • Nomad도 좋지만 여전히 컨트롤 플레인이 존재함
    • Nomad는 학습 곡선이 꽤 있음. 반면 Uncloud는 Docker와 Compose를 아는 사람이라면 거의 즉시 사용 가능함
    • HashiCorp의 라이선스는 수정 후 SaaS 형태로 제공하는 걸 금지함.
      즉, 직접 호스팅 외에는 활용이 제한되어 있고, 사실상 자유로운 서비스화가 불가능함. 라이선스 전문 참고

  • 참고로, 흥미로운 p2p 구성요소 두 가지를 공유함

답변달기