Uncloud - Kubernetesの複雑さなしにサーバー間でコンテナアプリをデプロイするツール

 (uncloud.run)
23 ポイント 投稿者 GN⁺ 2025-12-06 | 1件のコメント | WhatsAppで共有
  • Uncloudは、Kubernetesなしでも複数のサーバーにコンテナ化されたWebアプリケーションをデプロイしてスケールできるオープンソースツール
  • Docker Composeベースのワークフローを維持しながら、無停止デプロイ・自動HTTPS・サーバー間スケーリングをサポート
  • 中央コントロールプレーンなしで、各マシンがWireGuardベースのP2Pネットワークで接続され、一部のサーバーがオフラインでもクラスター運用を維持
  • Caddyリバースプロキシによる自動HTTPS、組み込みDNSベースのサービスディスカバリー、ロードバランシング機能を含む
  • クラウド・オンプレミス混在環境でも同じ方法でデプロイでき、インフラの制御権とコスト予測性を確保

PaaSライクなワークフロー

  • HerokuやFly.ioのようなシンプルなデプロイ体験を提供しつつ、サーバーとデータに対する完全な制御権を維持
    • リクエスト単位課金ではない予測可能なコスト構造
    • ベンダーロックインなし、標準的なSSHツールでデバッグ可能
  • Docker Composeに親和的な構成で、ビルド・プッシュ・デプロイを1つのコマンドで実行
    • イメージレジストリ不要、無停止ローリングデプロイをサポート
    • 複数マシンにまたがるレプリカスケーリングが可能

低メンテナンス設計

  • コントロールプレーンやクォーラム管理が不要で、運用の複雑さを最小化
  • ポート開放なしで安全なマシン間通信をサポート
  • 自動サービスディスカバリーとLet's EncryptベースのHTTPS自動発行機能を内蔵

動作の仕組み

  • 複雑なクラスターの代わりにシンプルなマシンネットワークで構成し、保守負担を抑えつつ安定したインフラを提供
  • 各マシンはWireGuardメッシュネットワークに参加し、自動ピア検出とNATトラバーサルを実行
    • コンテナは固有のIPを受け取り、サーバー間で直接通信可能
  • 完全分散型アーキテクチャにより、中央制御ノードなしで各マシンがクラスター状態を同期
    • 一部のマシンがオフラインでもクラスター運用を継続
  • DockerライクなCLIでインフラ全体を制御
    • 単一マシンへのSSHアクセスだけでデプロイ・監視・スケーリングを実行可能

主な機能

  • どこにでもデプロイ可能: クラウドVM、専用サーバー、オンプレミスなど、あらゆるLinuxマシンをサポート
  • 自動HTTPS: 組み込みのCaddyリバースプロキシにより、設定不要でTLS証明書を発行しHTTPSを有効化
  • ロードバランシング: 複数マシンに分散したコンテナレプリカ間でトラフィックを分配
  • サービスディスカバリー: 組み込みDNSがネットワーク内のサービス位置を自動追跡
  • Infrastructure as Code: 既存のDocker Composeファイルでアプリスタック全体を定義可能
  • ベンダーロックインなし: クラウドと自社ハードウェアを自由に組み合わせて利用可能

関連記事

1件のコメント

 
GN⁺ 2025-12-06
Hacker Newsのコメント

  • こんにちは、作者です。共有ありがとうございます。
    Uncloud はコントロールプレーンのないコンテナオーケストレーターです。簡単に言うと、自動 WireGuard メッシュ、サービスディスカバリー、Caddy による HTTPS が付いた、複数マシンにまたがる Docker Compose のようなものです。各マシンは 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 の中核機能です。
    数百ノード、1万前後のコンテナ程度なら、マネージドクラスターで自動更新されるため大きな負担ではありません。人々が自分で K8s を セルフホストして苦労していることが、こうした代替の背景なのか気になります。

    • 「数百ノード、1万コンテナ」が小さいとは感じません。私の規模は 2〜5 台のノード、10〜30 個のコンテナ程度ですが、このくらいだと K8s は重すぎます。こうした小規模企業は多いと思います。
    • 失礼な質問ではありません。コントロールプレーンがない利点は、すべてのマシンが対等な ピア構成になることで単純化される点です。中央集権的な「クラスターの頭脳」がないので、HA 構成や etcd クォーラムの問題を心配する必要がありません。
      ネットワークが分断されても、各パーティションは独立して動作できます。昔の Chef や Ansible の時代の単純さに、K8s から得た教訓を加えたようなものです。
    • もちろん、人々は K8s のセルフホスティングを試みます。バックアップと同じで、前もってやっておかないと必要なときにできません。
    • 中小企業にとって、1万コンテナは決して小さくありません。私は 10 個未満ですが、高可用性 (HA) が必要です。Uncloud は自分の状況によく合いそうです。
    • 「1万コンテナが小さいって、それ CI ジョブの数字じゃないの？ ;)」

  • すばらしいプロジェクトです。いずれぜひ使ってみたいです。
    よりシンプルな代替を探しているなら、Kamal もよいと思います。これは K8s やクラウドから完全に離れた企業が自ら運用しており、本番で実証済みのツールです。

  • サーバーを指定したときに セキュリティ強化(server hardening) を自動で行う機能があるのか気になります。

  • 私は Docker Swarm ユーザーです。Uncloud は久しぶりに興味を引かれた代替です。
    気になる点は次のとおりです。

    • secrets のサポート予定はあるか
    • Swarm+Traefik のように、コンテナラベルで URL rewrite ルールを定義できるか
    • 2 つの Compose スタックをデプロイした場合、異なるスタックのコンテナ間でネットワークアクセスが可能か
    • ドメインと内部ポートのマッピングは、Compose ファイルで x-ports: app.example.com:8000/https として定義します。
      または x-caddy: Caddyfile で Caddy 設定をカスタマイズできます。詳しくは 公式ドキュメント を参照してください。
      現時点ではスタック間のネットワーク 分離機能はありません。関連議論は GitHub Discussion #94 で進んでいます。
      どのような動作を期待しているのか気になります。
    • secrets 機能は issue #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 コンポーネントを 2 つ共有します。