Option

Verwalten Sie einen Uncloud-Cluster – stellen Sie Dienste bereit, konfigurieren Sie Caddy Ingress, fügen Sie statische Proxy-Routen für Geräte außerhalb des Clusters hinzu, veröffentlichen Sie Ports, skalieren Sie den Cluster, überprüfen Sie Protokolle und verwalten Sie Maschinen und Volumes mit der `uc`-Befehlszeilenschnittstelle.

...Alle erweitern
0
Zeit aktualisiert 30. September 2026

Uncloud Cluster-Verwaltung

Referenz für die uc CLI – einer dezentralen Self-Hosting-Plattform, die Docker-Container, WireGuard-Mesh-Netzwerke und den Caddy-Reverse-Proxy nutzt.

Wann aktivieren?

Verwenden Sie diese Funktion bei der Arbeit mit „Uncloud“-Clustern, insbesondere wenn:

  • Maschinen mit uc machine
  • Dienste aus Compose-Dateien bereitstellen mit uc deploy
  • HTTP-, HTTPS-, TCP- oder UDP-Ports über „Uncloud“ veröffentlichen
  • Caddy-Ingress konfigurieren mit x-caddy, x-portsoder --caddyfile
  • Weiterleitung externer LAN-Geräte über den Cluster-Proxy
  • Überprüfen von Protokollen, Dienststatus, Volumes, DNS oder Maschinenplatzierung

So funktioniert es

Uncloud führt Docker-Dienste auf Peer-Maschinen aus, die über ein WireGuard-Mesh miteinander verbunden sind. Jede Maschine ist ein gleichberechtigtes Cluster-Mitglied; Dienste kommunizieren über das Overlay-Netzwerk, und Caddy läuft global, um den öffentlichen HTTP/HTTPS-Datenverkehr zu terminieren. Compose-Dateien können „Uncloud“-Erweiterungen für Ingress, Platzierung und die generierte Caddy-Konfiguration verwenden, während die uc CLI die Bildverteilung, Planung, Skalierung, Protokollierung und den Cluster-Status verwaltet.

Beispiele

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

Kernkonzepte

  • Keine zentrale Steuerungsebene – alle Rechner sind gleichberechtigte Peers, die über WireGuard verbunden sind
  • Caddy läuft als globaler Dienst auf jeder Maschine; TLS-Zertifikate werden automatisch von Let’s Encrypt bezogen
  • Overlay-Netzwerk – Dienste kommunizieren standardmäßig über 10.210.0.0/16 standardmäßig; DNS wird innerhalb des Meshes bereitgestellt
  • Die Caddyfile wird automatisch generiert – bearbeiten Sie sie niemals direkt; verwenden Sie x-caddy / --caddyfile stattdessen

CLI-Kurzanleitung

Rechner

Befehl Zweck
uc machine init user@host Erste Maschine einrichten / neuen Cluster erstellen
uc machine add user@host Rechner einem bestehenden Cluster hinzufügen
uc machine ls Maschinen auflisten
uc machine update NAME --public-ip IP Öffentliche IP-Adresse für den eingehenden Datenverkehr aktualisieren
uc machine rm NAME Rechner entfernen

Schlüssel init Flags: --name, --network 10.210.0.0/16, --no-caddy, --no-dns, --public-ip auto\|IP\|none

Dienste

Befehl Zweck
uc service ls / uc ls Dienste auflisten
uc service run IMAGE Einen einzelnen Container-Dienst ausführen
uc deploy Bereitstellen aus compose.yaml
uc deploy --no-build Bereits gepushte Images bereitstellen, ohne sie neu zu erstellen
uc deploy --recreate Neuerstellung des Dienstes erzwingen
uc scale SERVICE N Anzahl der Replikate festlegen
uc service logs SERVICE Protokolle anzeigen
uc service exec SERVICE Über die Shell in den Container zugreifen
uc service inspect SERVICE Detaillierte Informationen
uc service rm SERVICE Dienst entfernen (behält benannte Volumes bei)
uc ps Alle Container im gesamten Cluster

Images

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

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 & Kontext

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

Portweiterleitung

HTTP/HTTPS (über Caddy-Reverse-Proxy)

-p [hostname:]container_port[/protocol]
Beispiel Bedeutung
-p 8080/https HTTPS mit automatischer service-name.cluster-domain Hostnamen
-p app.example.com:8080/https HTTPS mit benutzerdefiniertem Hostnamen
-p 8080/http Nur HTTP, kein TLS

TCP/UDP (hostgebunden, umgeht Caddy)

-p [host_ip:]host_port:container_port[/protocol]@host
Beispiel Bedeutung
-p 5432:5432@host TCP 5432 auf allen Schnittstellen
-p 127.0.0.1:5432:5432@host TCP 5432 nur Loopback
-p 53:5353/udp@host UDP

Erweiterungen der Compose-Datei

Uncloud fügt zusätzlich zu Docker Compose folgende Erweiterungen hinzu:

x-ports — Veröffentlichungsports mit Domains

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

x-caddy — benutzerdefinierte Caddy-Konfiguration für den Dienst

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$...
        }
      }

Innerhalb der Vorlage verfügbare Funktionen x-caddy:

  • {{upstreams [service] [port]}} — IP-Adressen von funktionsfähigen Containern
  • {{.Name}} — Dienstname
  • {{.Upstreams}} — Zuordnung aller Dienste zu IP-Adressen

x-machines — Platzierungsbeschränkungen

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

Vollständiges Beispiel für mehrere Dienste

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:

Weiterleitung an externe (nicht zum Cluster gehörende) Geräte

So stellen Sie ein externes Gerät (z. B. BMC, NAS, Router-Benutzeroberfläche) über Caddy bereit, ohne einen echten Container auszuführen:

1. Erstellen Sie ein Caddyfile-Snippet (z. B. ~/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
}

Für Upstream im Klartext: reverse_proxy http://192.168.1.x:port

2. Registrieren Sie den Dienst als benannten Dienst mit einem No-Op-Container:

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

pause ist ein minimaler No-Op-Container – er führt keine Aktionen aus, stellt aber Uncloud einen Service-Eintrag zur Verfügung, an den das Caddyfile angehängt werden kann.

3. Überprüfen Sie:

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

--caddyfile kann nicht mit nicht@host veröffentlichten Ports kombiniert werden.

DNS-Tipp: Ein Wildcard-Eintrag (*.yourdomain.com → cluster-public-ip) bedeutet, dass jede neue Subdomain sofort funktioniert – es ist keine DNS-Änderung pro Dienst erforderlich.

Dienst-DNS (intern)

Dienste innerhalb des Clusters erkennen sich gegenseitig anhand ihres Namens:

DNS-Name Wird aufgelöst zu
service-name Jeden funktionsfähigen Container
service-name.internal Gleich
rr.service-name.internal Round-Robin
nearest.service-name.internal Zunächst lokal auf dem Rechner

Skalierung und globale Dienste

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

Vorlagen für Image-Tags (in „compose.yaml“)

image: myapp:{{gitdate "20060102"}}.{{gitsha 7}}
image: myapp:{{gitsha 7}}.${GITHUB_RUN_ID:-local}
Funktion Ausgabe
{{gitsha N}} Die ersten N Zeichen des Commit-SHA
{{gitdate "format"}} Git-Commit-Datum im Go-Format
{{date "format"}} Aktuelles Datum

Gängige Arbeitsabläufe

Aus dem Quellcode bereitstellen:

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

Dienst überprüfen:

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

Bereitstellungen ohne Ausfallzeiten erfolgen automatisch; „Uncloud“ wartet auf den Abschluss der Zustandsprüfungen, bevor alte Container beendet werden.

Neuerstellung erzwingen:

uc deploy --recreate

Häufige Fehler

Fehler Behebung
Direkte Bearbeitung der Caddyfile Verwenden Sie x-caddy im Modus „Verfassen“ oder --caddyfile auf uc service run
Proxying eines HTTPS-Upstreams mit selbstsigniertem Zertifikat Fügen Sie transport http { tls_insecure_skip_verify }
uc caddy config zeigt keine benutzerdefinierten Blöcke an Caddy-Admin-Socket nicht erreichbar – bitte überprüfen uc inspect caddy und uc logs caddy
Der Dienst kann die externe LAN-IP-Adresse vom Container aus nicht erreichen Überprüfen Sie, ob der Host des Caddy-Containers das Zielnetzwerk erreichen kann
Volumes gehen verloren nach uc service rm Benannte Volumes bleiben bestehen; nur anonyme Volumes werden automatisch entfernt
Auf GitHub ansehen
---
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 |

Alle Dateien

1 Dateien

uncloud installieren

Laden Sie die Skill-Dateien herunter und entpacken Sie sie in Ihr Verzeichnis „.claude/skills/“.

ZIP herunterladen

Klonen Sie das Repository und kopieren Sie die Skill-Dateien in Ihr Projekt.

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

Kopieren Kopieren
Schnelle Einrichtung: Kopiere den Skill-Ordner nach .claude/skills/ Claude erkennt den Skill automatisch und nutzt ihn.
Repository affaan-m/ECC

Ähnliche Skills

klingai-upgrade-migration
Zeit aktualisiert 3. Juli 2026
Verification & Quality Assurance
Zeit aktualisiert 29. Juni 2026
base44-cli
Zeit aktualisiert 29. Juni 2026
Railway CLI Management
Zeit aktualisiert 2. Juli 2026
OR