안녕하세요, 제작자임. 공유해줘서 고마움 Uncloud는 컨트롤 플레인이 없는 컨테이너 오케스트레이터임. 쉽게 말해, 여러 머신에 걸친 Docker Compose에 자동 WireGuard 메시, 서비스 디스커버리, Caddy를 통한 HTTPS가 붙은 형태임. 각 머신은 Fly.io의 Corrosion을 이용해 클러스터 상태를 p2p 동기화함으로써 쿼럼 유지가 필요 없음
Kubernetes를 스타트업과 유니콘 기업 양쪽에서 운영해온 경험 끝에, 대부분의 팀이 사실은 단지 몇 대의 머신에서 컨테이너를 잘 돌리고 네트워킹과 롤아웃, HTTPS만 필요하다는 걸 깨달았음. K8s의 운영 오버헤드는 그에 비해 너무 큼
주요 특징은 다음과 같음
익숙한 Docker Compose 스펙 사용, 새로운 DSL 학습 불필요
외부 레지스트리 없이 직접 머신에 Docker 이미지를 빌드·푸시 (내 다른 프로젝트 unregistry 사용)
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가 개선할 수 있을 부분이 무엇인지 궁금함
Hacker News 의견
안녕하세요, 제작자임. 공유해줘서 고마움
Uncloud는 컨트롤 플레인이 없는 컨테이너 오케스트레이터임. 쉽게 말해, 여러 머신에 걸친 Docker Compose에 자동 WireGuard 메시, 서비스 디스커버리, Caddy를 통한 HTTPS가 붙은 형태임. 각 머신은 Fly.io의 Corrosion을 이용해 클러스터 상태를 p2p 동기화함으로써 쿼럼 유지가 필요 없음
Kubernetes를 스타트업과 유니콘 기업 양쪽에서 운영해온 경험 끝에, 대부분의 팀이 사실은 단지 몇 대의 머신에서 컨테이너를 잘 돌리고 네트워킹과 롤아웃, HTTPS만 필요하다는 걸 깨달았음. K8s의 운영 오버헤드는 그에 비해 너무 큼
주요 특징은 다음과 같음
프로젝트 링크: https://github.com/psviderski/uncloud
uc machine init이 내부적으로 root 권한으로curl | bash를 실행하는 방식은 보안상 위험해 보임. 테스트는 해보고 싶지만 실제 머신에서는 돌리지 않을 것 같음커리어 대부분을 Kubernetes로 보냈는데, 컨트롤 플레인이 없는 구조의 장점이 무엇인지 궁금함. 내게는 컨트롤 플레인이야말로 K8s의 핵심 기능임.
수백 노드, 만여 개 컨테이너 정도는 관리형 클러스터로 자동 업데이트되기 때문에 큰 부담이 없음. 사람들이 직접 K8s를 셀프호스팅하면서 겪는 고통이 이런 대안의 배경인지 궁금함
네트워크가 분할되어도 각 파티션이 독립적으로 동작 가능함. 예전 Chef나 Ansible 시절의 단순함에 K8s의 교훈을 더한 형태임
프로젝트가 멋짐. 나중에 꼭 써볼 생각임.
더 단순한 대안을 찾는다면 Kamal도 괜찮음. 이건 K8s와 클라우드를 완전히 벗어난 회사가 직접 운영하며 실전 검증된 툴임
서버를 지정했을 때 보안 강화(server hardening) 를 자동으로 해주는 기능이 있는지 궁금함
나는 Docker Swarm 사용자임. Uncloud는 처음으로 흥미롭게 느껴지는 대안임
궁금한 점은 다음과 같음
x-ports: app.example.com:8000/https로 정의함.또는
x-caddy: Caddyfile로 Caddy 설정을 커스터마이징 가능함. 자세한 내용은 공식 문서 참고현재는 스택 간 네트워크 격리 기능이 없음. 관련 논의는 GitHub Discussion #94에서 진행 중임.
어떤 동작을 기대하는지 궁금함
2, 3번 질문의 답은 “아직은 아니고”, “현재는 예”임. 관련 논의는 Discussion #94 참고
Swarm을 써본 입장에서, Swarm이 부족하거나 불편했던 점 중 Uncloud가 개선할 수 있을 부분이 무엇인지 궁금함
정말 멋진 프로젝트임. 비슷한 주제의 다른 툴들도 참고할 만함
더 알고 있다면 추가해줬으면 함
최근 Coolify를 써봤는데 다소 미완성 느낌이었음. 현재는 Dokku를 쓰고 있지만, DB 관리용 UI가 더 나아졌으면 함
나는 k3s에 만족하지만, Docker Compose와 완전한 K8s 사이의 중간 지대에서 새로운 시도가 나오는 게 반가움. 특히 WireGuard 통합이 흥미로움
정말 멋진 툴임. 수고에 감사함.
백엔드의 상태 복제(state replication) 가 어떻게 동작하는지 궁금함. CRDT와 gossip 프로토콜을 언급했지만 구체적인 구현이 모호함
K8s가 아니라면 왜 Nomad가 아닌가?
즉, 직접 호스팅 외에는 활용이 제한되어 있고, 사실상 자유로운 서비스화가 불가능함. 라이선스 전문 참고
참고로, 흥미로운 p2p 구성요소 두 가지를 공유함