オプション

Uncloud クラスターの管理 — `uc` CLI を使用して、サービスのデプロイ、Caddy Ingress の設定、クラスター外デバイスへの静的プロキシルートの追加、ポートの公開、スケーリング、ログの確認、およびマシンやボリュームの管理を行います。

...すべて拡張します
0
更新された時間 2026年9月30日

Uncloud クラスタ管理

CLI リファレンス uc CLI — Dockerコンテナ、WireGuardメッシュネットワーク、およびCaddyリバースプロキシを活用した分散型セルフホスティングプラットフォーム。

有効化すべきタイミング

Uncloudクラスタを扱う際、特に以下の場合にこのスキルを使用してください:

  • 以下の方法でマシンのブートストラップまたはクラスタへの参加を行う場合 uc machine
  • Compose ファイルからのサービスデプロイ uc deploy
  • Uncloud 経由で HTTP、HTTPS、TCP、または UDP ポートを公開する場合
  • CaddyのIngressを構成する場合 x-caddy, x-ports、または --caddyfile
  • クラスタープロキシを経由して外部LANデバイスをルーティングする
  • ログ、サービスの状態、ボリューム、DNS、またはマシンの配置を確認する

仕組み

Uncloud は、WireGuardメッシュで接続されたピアマシン間でDockerサービスを実行します。各マシンは対等なクラスターメンバーであり、サービスはオーバーレイネットワーク上で通信し、Caddyはグローバルに実行されてパブリックなHTTP/HTTPSトラフィックを処理します。Composeファイルでは、Uncloud拡張機能を使用して、Ingress、配置、および生成されたCaddy設定を指定できます。一方、 uc CLIは、イメージの配布、スケジューリング、スケーリング、ログ、およびクラスタの状態を管理します。

例

uc machine init user@host --name machine-1
uc service run --name web -p app.example.com:8080/https nginx:latest
uc deploy

基本概念

  • 中央制御プレーンなし — すべてのマシンは、WireGuardで接続された対等なピアです
  • Caddyはすべてのマシン上でグローバルサービスとして実行され、Let's EncryptからTLS証明書を自動取得します
  • オーバーレイネットワーク — サービスは 10.210.0.0/16 を介して通信します。DNSはメッシュ内で提供されます
  • Caddyfileは自動生成されるため、直接編集してはいけません。代わりに x-caddy / --caddyfile を使用してください

CLI クイックリファレンス

マシン

コマンド 目的
uc machine init user@host 最初のマシンのブートストラップ / 新しいクラスタの作成
uc machine add user@host マシンを既存のクラスタに参加させる
uc machine ls マシンの一覧表示
uc machine update NAME --public-ip IP インジェスト用のパブリックIPを更新する
uc machine rm NAME マシンの削除

キー init フラグ: --name, --network 10.210.0.0/16, --no-caddy, --no-dns, --public-ip auto\|IP\|none

サービス

コマンド 目的
uc service ls / uc ls サービスのリスト表示
uc service run IMAGE 単一のコンテナ・サービスを実行する
uc deploy デプロイ元 compose.yaml
uc deploy --no-build 再構築せずに、すでにプッシュ済みのイメージをデプロイする
uc deploy --recreate サービスの再作成を強制する
uc scale SERVICE N レプリカ数を設定する
uc service logs SERVICE ログを表示
uc service exec SERVICE コンテナへのシェル接続
uc service inspect SERVICE 詳細情報
uc service rm SERVICE サービスの削除(名前付きボリュームは保持)
uc ps クラスタ全体のすべてのコンテナ

イメージ

uc image push myapp:latest                    # Push local image to all machines
uc image push myapp:latest -m machine1,machine2  # Push to specific machines
uc images                                     # List images in cluster

ボリューム

uc volume ls                  # All volumes
uc volume ls -m machine1      # On specific machine
uc volume create NAME -m MACHINE
uc volume rm NAME

Caddy

uc caddy config    # Show current generated Caddyfile (read-only)
uc caddy deploy    # Deploy/upgrade Caddy across cluster

DNS およびコンテキスト

uc dns show        # Show reserved *.uncld.dev domain
uc dns reserve     # Reserve a new domain
uc ctx ls          # List cluster contexts
uc ctx use prod    # Switch context

ポート公開

HTTP/HTTPS(Caddyのリバースプロキシ経由)

-p [hostname:]container_port[/protocol]
例 意味
-p 8080/https 自動設定によるHTTPS service-name.cluster-domain ホスト名
-p app.example.com:8080/https カスタムホスト名を使用したHTTPS
-p 8080/http HTTPのみ、TLSなし

TCP/UDP(ホストに紐付け、Caddyをバイパス)

-p [host_ip:]host_port:container_port[/protocol]@host
例 意味
-p 5432:5432@host すべてのインターフェースでTCP 5432
-p 127.0.0.1:5432:5432@host TCP 5432(ループバックのみ)
-p 53:5353/udp@host UDP

Compose ファイルの拡張機能

Uncloud Docker Compose に以下の拡張機能を追加します:

x-ports — ドメイン付きでポートを公開

services:
  app:
    image: app:latest
    x-ports:
      - example.com:8000/https
      - www.example.com:8000/https
      - api.example.com:9000/https

x-caddy — サービス用のカスタム Caddy 設定

services:
  app:
    image: app:latest
    x-caddy: |
      example.com {
        redir https://www.example.com{uri} permanent
      }
      www.example.com {
        reverse_proxy {{upstreams 8000}} {
          import common_proxy
        }
        basic_auth /admin/* {
          admin $2a$14$...
        }
      }

内部で利用可能なテンプレート関数 x-caddy:

  • {{upstreams [service] [port]}} — 正常に動作しているコンテナのIPアドレス
  • {{.Name}} — サービス名
  • {{.Upstreams}} — すべてのサービスとIPアドレスの対応表

x-machines — 配置制約

services:
  db:
    image: postgres:18
    x-machines: db-machine          # Single machine name
  app:
    image: app:latest
    x-machines:
      - machine-1
      - machine-2

完全なマルチサービス例

services:
  api:
    build: ./api
    x-ports:
      - api.example.com:3000/https
    environment:
      DATABASE_URL: postgres://db:5432/mydb

  web:
    build: ./web
    x-ports:
      - example.com:8000/https
      - www.example.com:8000/https
    environment:
      API_URL: http://api:3000

  db:
    image: postgres:18
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db-data:/var/lib/postgresql/data
    x-machines: db-machine

volumes:
  db-data:

外部(クラスタ外)デバイスへのルーティング

実際のコンテナを実行せずに、Caddyを介して外部デバイス(例:BMC、NAS、ルーターのUI)を公開するには:

1. Caddyfileのスニペットを作成します(例: ~/device.caddyfile):

https://device.example.com {
    reverse_proxy https://192.168.1.x {
        transport http {
            tls_insecure_skip_verify   # needed for self-signed BMC certs
        }
    }
    log
}

プレーンテキストのアップストリームの場合: reverse_proxy http://192.168.1.x:port

2. ノーオペレーション(no-op)コンテナを使用して、名前付きサービスとして登録します:

uc service run \
  --name device-bmc \
  --caddyfile ~/device.caddyfile \
  registry.k8s.io/pause:3.9

pause は最小限のノーオペレーション・コンテナです。何も実行しませんが、Uncloudに、Caddyfileをアタッチするためのサービスエントリを提供します。

3. 確認:

uc caddy config   # device.example.com block should appear

--caddyfile は、公開されていないポートとは組み合わせることができません。@host 公開されていないポートとは併用できません。

DNSのヒント:ワイルドカードレコード(*.yourdomain.com → cluster-public-ip)を使用することで、新しいサブドメインが即座に機能します。サービスごとにDNS設定を変更する必要はありません。

サービスDNS(内部)

クラスタ内のサービスは、名前によって相互に解決されます:

DNS名 解決先
service-name 正常なコンテナ
service-name.internal 同じ
rr.service-name.internal ラウンドロビン
nearest.service-name.internal マシンローカル優先

スケーリングとグローバルサービス

uc scale web 5    # 5 replicas (spread across machines)
uc scale web 1    # Scale down
services:
  caddy:
    deploy:
      mode: global   # One container on every machine

イメージタグテンプレート(compose.yaml内)

image: myapp:{{gitdate "20060102"}}.{{gitsha 7}}
image: myapp:{{gitsha 7}}.${GITHUB_RUN_ID:-local}
関数 出力
{{gitsha N}} コミット SHA の先頭 N 文字
{{gitdate "format"}} Go形式のGitコミット日時
{{date "format"}} 現在の日付

一般的なワークフロー

ソースからのデプロイ:

uc deploy                          # Build + push + deploy
uc build --push && uc deploy --no-build   # Separate steps

サービスの状態確認:

uc inspect web
uc logs -f web
uc logs --since 1h web
uc exec web                        # Opens shell
uc exec web /bin/sh -c "env"       # Run specific command

ダウンタイムゼロのデプロイは自動的に行われます。Uncloudは、ヘルスチェックの結果を待ってから古いコンテナを終了させます。

強制再作成:

uc deploy --recreate

よくあるミス

間違い 修正
Caddyfileを直接編集する 「 x-caddy compose 内で使用するか、 --caddyfile で uc service run
自己署名証明書を使用したHTTPSアップストリームのプロキシ設定 次のように追加します transport http { tls_insecure_skip_verify }
uc caddy config にはユーザー定義のブロックが表示されない Caddy 管理ソケットに接続できません — 確認してください uc inspect caddy および uc logs caddy
コンテナから外部LAN IPに到達できない Caddy コンテナのホストから対象ネットワークへルーティングできることを確認してください
以下の操作後にボリュームが消失しました uc service rm 名前付きボリュームは永続化されます。自動削除されるのは匿名ボリュームのみです
GitHubで見る
---
name: uncloud
description: Manage an Uncloud cluster — deploy services, configure Caddy ingress, add static proxy routes for non-cluster devices, publish ports, scale, inspect logs, and manage machines and volumes with the `uc` CLI.
---

# Uncloud Cluster Management

Reference for the `uc` CLI — a decentralised self-hosting platform using Docker containers, WireGuard mesh networking, and Caddy reverse proxy.

## When to Activate

Use this skill when working with Uncloud clusters, especially when:
- Bootstrapping or joining machines with `uc machine`
- Deploying services from Compose files with `uc deploy`
- Publishing HTTP, HTTPS, TCP, or UDP ports through Uncloud
- Configuring Caddy ingress with `x-caddy`, `x-ports`, or `--caddyfile`
- Routing external LAN devices through the cluster proxy
- Inspecting logs, service state, volumes, DNS, or machine placement

## How It Works

Uncloud runs Docker services across peer machines connected by a WireGuard mesh. Each machine is an equal cluster member; services communicate on the overlay network and Caddy runs globally to terminate public HTTP/HTTPS traffic. Compose files can use Uncloud extensions for ingress, placement, and generated Caddy configuration, while the `uc` CLI handles image distribution, scheduling, scaling, logs, and cluster state.

## Examples

```bash
uc machine init user@host --name machine-1
uc service run --name web -p app.example.com:8080/https nginx:latest
uc deploy
```

## Core Concepts

- **No central control plane** — all machines are equal peers connected by WireGuard
- **Caddy** runs as a global service on every machine; auto-obtains TLS from Let's Encrypt
- **Overlay network** — services communicate via `10.210.0.0/16` by default; DNS provided inside the mesh
- **Caddyfile is autogenerated** — never edit it directly; use `x-caddy` / `--caddyfile` instead

---

## CLI Quick Reference

### Machines

| Command | Purpose |
|---------|---------|
| `uc machine init user@host` | Bootstrap first machine / new cluster |
| `uc machine add user@host` | Join machine to existing cluster |
| `uc machine ls` | List machines |
| `uc machine update NAME --public-ip IP` | Update public IP for ingress |
| `uc machine rm NAME` | Remove machine |

Key `init` flags: `--name`, `--network 10.210.0.0/16`, `--no-caddy`, `--no-dns`, `--public-ip auto\|IP\|none`

### Services

| Command | Purpose |
|---------|---------|
| `uc service ls` / `uc ls` | List services |
| `uc service run IMAGE` | Run a single container service |
| `uc deploy` | Deploy from `compose.yaml` |
| `uc deploy --no-build` | Deploy already-pushed images without rebuilding |
| `uc deploy --recreate` | Force service recreation |
| `uc scale SERVICE N` | Set replica count |
| `uc service logs SERVICE` | View logs |
| `uc service exec SERVICE` | Shell into container |
| `uc service inspect SERVICE` | Detailed info |
| `uc service rm SERVICE` | Remove service (keeps named volumes) |
| `uc ps` | All containers across cluster |

### Images

```bash
uc image push myapp:latest                    # Push local image to all machines
uc image push myapp:latest -m machine1,machine2  # Push to specific machines
uc images                                     # List images in cluster
```

### Volumes

```bash
uc volume ls                  # All volumes
uc volume ls -m machine1      # On specific machine
uc volume create NAME -m MACHINE
uc volume rm NAME
```

### Caddy

```bash
uc caddy config    # Show current generated Caddyfile (read-only)
uc caddy deploy    # Deploy/upgrade Caddy across cluster
```

### DNS & Context

```bash
uc dns show        # Show reserved *.uncld.dev domain
uc dns reserve     # Reserve a new domain
uc ctx ls          # List cluster contexts
uc ctx use prod    # Switch context
```

---

## Port Publishing

### HTTP/HTTPS (via Caddy reverse proxy)

```
-p [hostname:]container_port[/protocol]
```

| Example | Meaning |
|---------|---------|
| `-p 8080/https` | HTTPS with auto `service-name.cluster-domain` hostname |
| `-p app.example.com:8080/https` | HTTPS with custom hostname |
| `-p 8080/http` | HTTP only, no TLS |

### TCP/UDP (host-bound, bypasses Caddy)

```
-p [host_ip:]host_port:container_port[/protocol]@host
```

| Example | Meaning |
|---------|---------|
| `-p 5432:5432@host` | TCP 5432 on all interfaces |
| `-p 127.0.0.1:5432:5432@host` | TCP 5432 loopback only |
| `-p 53:5353/udp@host` | UDP |

---

## Compose File Extensions

Uncloud adds these extensions on top of Docker Compose:

### `x-ports` — publish ports with domains

```yaml
services:
  app:
    image: app:latest
    x-ports:
      - example.com:8000/https
      - www.example.com:8000/https
      - api.example.com:9000/https
```

### `x-caddy` — custom Caddy config for service

```yaml
services:
  app:
    image: app:latest
    x-caddy: |
      example.com {
        redir https://www.example.com{uri} permanent
      }
      www.example.com {
        reverse_proxy {{upstreams 8000}} {
          import common_proxy
        }
        basic_auth /admin/* {
          admin $2a$14$...
        }
      }
```

Template functions available inside `x-caddy`:
- `{{upstreams [service] [port]}}` — healthy container IPs
- `{{.Name}}` — service name
- `{{.Upstreams}}` — map of all services → IPs

### `x-machines` — placement constraints

```yaml
services:
  db:
    image: postgres:18
    x-machines: db-machine          # Single machine name
  app:
    image: app:latest
    x-machines:
      - machine-1
      - machine-2
```

### Full multi-service example

```yaml
services:
  api:
    build: ./api
    x-ports:
      - api.example.com:3000/https
    environment:
      DATABASE_URL: postgres://db:5432/mydb

  web:
    build: ./web
    x-ports:
      - example.com:8000/https
      - www.example.com:8000/https
    environment:
      API_URL: http://api:3000

  db:
    image: postgres:18
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db-data:/var/lib/postgresql/data
    x-machines: db-machine

volumes:
  db-data:
```

---

## Routing to External (Non-Cluster) Devices

To expose an external device (e.g. BMC, NAS, router UI) via Caddy without running a real container:

**1. Create a Caddyfile snippet** (e.g. `~/device.caddyfile`):

```caddyfile
https://device.example.com {
    reverse_proxy https://192.168.1.x {
        transport http {
            tls_insecure_skip_verify   # needed for self-signed BMC certs
        }
    }
    log
}
```

For plaintext upstream: `reverse_proxy http://192.168.1.x:port`

**2. Register as a named service with no-op container:**

```bash
uc service run \
  --name device-bmc \
  --caddyfile ~/device.caddyfile \
  registry.k8s.io/pause:3.9
```

`pause` is a minimal no-op container — it does nothing, but gives Uncloud a service entry to attach the Caddyfile to.

**3. Verify:**

```bash
uc caddy config   # device.example.com block should appear
```

> `--caddyfile` cannot be combined with non-`@host` published ports.

**DNS tip:** A wildcard record (`*.yourdomain.com → cluster-public-ip`) means any new subdomain works immediately — no DNS change needed per service.

---

## Service DNS (Internal)

Services inside the cluster resolve each other by name:

| DNS name | Resolves to |
|----------|------------|
| `service-name` | Any healthy container |
| `service-name.internal` | Same |
| `rr.service-name.internal` | Round-robin |
| `nearest.service-name.internal` | Machine-local first |

---

## Scaling & Global Services

```bash
uc scale web 5    # 5 replicas (spread across machines)
uc scale web 1    # Scale down
```

```yaml
services:
  caddy:
    deploy:
      mode: global   # One container on every machine
```

---

## Image Tag Templates (in compose.yaml)

```yaml
image: myapp:{{gitdate "20060102"}}.{{gitsha 7}}
image: myapp:{{gitsha 7}}.${GITHUB_RUN_ID:-local}
```

| Function | Output |
|----------|--------|
| `{{gitsha N}}` | First N chars of commit SHA |
| `{{gitdate "format"}}` | Git commit date in Go format |
| `{{date "format"}}` | Current date |

---

## Common Workflows

**Deploy from source:**
```bash
uc deploy                          # Build + push + deploy
uc build --push && uc deploy --no-build   # Separate steps
```

**Inspect a service:**
```bash
uc inspect web
uc logs -f web
uc logs --since 1h web
uc exec web                        # Opens shell
uc exec web /bin/sh -c "env"       # Run specific command
```

**Zero-downtime deploys** happen automatically; Uncloud waits for health checks before terminating old containers.

**Force recreate:**
```bash
uc deploy --recreate
```

---

## Common Mistakes

| Mistake | Fix |
|---------|-----|
| Editing the Caddyfile directly | Use `x-caddy` in compose or `--caddyfile` on `uc service run` |
| Proxying an HTTPS upstream with self-signed cert | Add `transport http { tls_insecure_skip_verify }` |
| `uc caddy config` shows no user-defined blocks | Caddy admin socket unreachable — check `uc inspect caddy` and `uc logs caddy` |
| Service can't reach external LAN IP from container | Verify Caddy container's host can route to target network |
| Volumes lost after `uc service rm` | Named volumes persist; only anonymous volumes are auto-removed |

すべてのファイル

1件のファイル

uncloudをインストール

スキルファイルをダウンロードし、.claude/skills/ ディレクトリに解凍してください。

ZIPをダウンロード

リポジトリをクローンし、スキルファイルをプロジェクトにコピーしてください。

git clone https://github.com/affaan-m/ECC/tree/main/skills/uncloud # Copy SKILL.md to your .claude/skills/ directory

コピー コピー
クイックセットアップ: スキルフォルダを .claude/skills/ にコピーしてください。 Claude が自動的にそのスキルを検出して使用します。
リポジトリ affaan-m/ECC

関連スキル

klingai-upgrade-migration
更新された時間 2026年7月3日
Verification & Quality Assurance
更新された時間 2026年6月29日
base44-cli
更新された時間 2026年6月29日
Railway CLI Management
更新された時間 2026年7月2日
OR