Dienste

Wenn Sie unsicher sind, welches Tool Sie verwenden sollen, lesen Sie rdc vs renet.

Diese Seite behandelt die Bereitstellung und Verwaltung containerisierter Dienste: Rediaccfiles, Dienst-Netzwerk, Starten/Stoppen, Massenoperationen und Autostart.

Das Rediaccfile

Das Rediaccfile ist ein Bash-Skript, das definiert, wie Ihre Dienste gestartet und gestoppt werden. Es muss Rediaccfile oder rediaccfile (Groß-/Kleinschreibung wird nicht unterschieden) heißen und im eingebundenen Dateisystem des Repositories platziert werden.

Rediaccfiles werden an zwei Orten gesucht:

Im Stammverzeichnis des Repository-Einbindungspfads
In Unterverzeichnissen der ersten Ebene des Einbindungspfads (nicht rekursiv)

Versteckte Verzeichnisse (Namen, die mit . beginnen) werden übersprungen.

Lebenszyklus-Funktionen

Ein Rediaccfile enthält bis zu zwei Funktionen:

Funktion	Ausführungszeitpunkt	Zweck	Fehlerverhalten
`up()`	Beim Starten	Dienste starten (z. B. `renet compose -- up -d`)	Fehler im Root-Rediaccfile sind kritisch (stoppt alles). Fehler in Unterverzeichnissen sind nicht-kritisch (werden protokolliert, es wird mit dem nächsten fortgefahren).
`down()`	Beim Stoppen	Dienste stoppen (z. B. `renet compose -- down`)	Best-Effort — Fehler werden protokolliert, aber alle Rediaccfiles werden immer verarbeitet.

Beide Funktionen sind optional. Wenn eine Funktion nicht definiert ist, wird sie stillschweigend übersprungen.

Ausführungsreihenfolge

Starten (up): Zuerst das Root-Rediaccfile, dann Unterverzeichnisse in alphabetischer Reihenfolge (A bis Z).
Stoppen (down): Unterverzeichnisse in umgekehrt alphabetischer Reihenfolge (Z bis A), dann zuletzt das Root.

Umgebungsvariablen

Wenn eine Rediaccfile-Funktion ausgeführt wird, stehen folgende Umgebungsvariablen zur Verfügung:

Variable	Beschreibung	Beispiel
`REDIACC_WORKING_DIR`	Einbindungspfad des Repositories	`/mnt/rediacc/mounts/abc123`
`REDIACC_REPOSITORY`	Repository-GUID	`a1b2c3d4-e5f6-...`
`REDIACC_NETWORK_ID`	Netzwerk-ID (Ganzzahl)	`2816`
`DOCKER_HOST`	Docker-Socket für den isolierten Daemon dieses Repositories	`unix:///var/run/rediacc/docker-2816.sock`
`{SERVICE}_IP`	Loopback-IP für jeden in `.rediacc.json` definierten Dienst	`POSTGRES_IP=127.0.11.2`

Die {SERVICE}_IP-Variablen werden automatisch aus .rediacc.json generiert. Die Namenskonvention wandelt den Dienstnamen in Großbuchstaben um, ersetzt Bindestriche durch Unterstriche und hängt _IP an. Zum Beispiel wird listmonk-app zu LISTMONK_APP_IP.

Warnung: Verwenden Sie kein sudo docker in Rediaccfiles. Der sudo-Befehl setzt Umgebungsvariablen zurück, wodurch DOCKER_HOST verloren geht und Docker-Befehle den System-Daemon statt des isolierten Repository-Daemons ansprechen. Dies bricht die Container-Isolation und kann Port-Konflikte verursachen. Rediacc blockiert die Ausführung, wenn es sudo docker ohne -E erkennt.

Verwenden Sie renet compose in Ihren Rediaccfiles — es übernimmt automatisch DOCKER_HOST, injiziert Netzwerk-Labels für die Routen-Erkennung und konfiguriert das Dienst-Netzwerk. Siehe Netzwerk für Details, wie Dienste über den Reverse Proxy bereitgestellt werden. Wenn Sie Docker direkt aufrufen, verwenden Sie docker ohne sudo — Rediaccfile-Funktionen laufen bereits mit ausreichenden Rechten. Wenn Sie sudo verwenden müssen, nutzen Sie sudo -E docker, um Umgebungsvariablen zu erhalten.

Beispiel

#!/bin/bash

up() {
    echo "Starting services..."
    renet compose -- up -d
}

down() {
    echo "Stopping services..."
    renet compose -- down
}

Wichtig: Verwenden Sie immer renet compose -- anstelle von docker compose. Der renet compose-Wrapper erzwingt Host-Networking, IP-Zuweisung und Service-Discovery-Labels, die von renet-proxy benötigt werden. CRIU-Checkpoint/Restore-Fähigkeiten werden zu Containern mit dem Label rediacc.checkpoint=true hinzugefügt. Die direkte Verwendung von docker compose wird durch die Rediaccfile-Validierung abgelehnt. Siehe Netzwerk für Details.

Multi-Service-Layout

Für Projekte mit mehreren unabhängigen Dienstgruppen verwenden Sie Unterverzeichnisse:

/mnt/rediacc/mounts/my-app/
├── Rediaccfile              # Root: gemeinsames Setup
├── docker-compose.yml
├── database/
│   ├── Rediaccfile          # Datenbankdienste
│   └── docker-compose.yml
├── backend/
│   ├── Rediaccfile          # API-Server
│   └── docker-compose.yml
└── monitoring/
    ├── Rediaccfile          # Prometheus, Grafana usw.
    └── docker-compose.yml

Ausführungsreihenfolge für up: Root, dann backend, database, monitoring (A-Z). Ausführungsreihenfolge für down: monitoring, database, backend, dann Root (Z-A).

Dienst-Netzwerk (.rediacc.json)

Jedes Repository erhält ein /26-Subnetz (64 IPs) im 127.x.x.x-Loopback-Bereich. Dienste binden sich an eindeutige Loopback-IPs, sodass sie auf denselben Ports ohne Konflikte laufen können.

Die .rediacc.json-Datei

Ordnet Dienstnamen Slot-Nummern zu. Jeder Slot entspricht einer eindeutigen IP-Adresse innerhalb des Repository-Subnetzes.

{
  "services": {
    "api": {"slot": 0},
    "postgres": {"slot": 1},
    "redis": {"slot": 2}
  }
}

Automatische Generierung aus Docker Compose

Sie müssen .rediacc.json nicht manuell erstellen. Wenn Sie rdc repo up ausführen, führt Rediacc automatisch folgende Schritte durch:

Durchsucht alle Verzeichnisse mit einem Rediaccfile nach Compose-Dateien (docker-compose.yml, docker-compose.yaml, compose.yml oder compose.yaml)
Extrahiert Dienstnamen aus dem services:-Abschnitt
Weist jedem neuen Dienst den nächsten verfügbaren Slot zu
Speichert das Ergebnis in {repository}/.rediacc.json

IP-Berechnung

Die IP eines Dienstes wird aus der Netzwerk-ID des Repositories und dem Slot des Dienstes berechnet. Die Netzwerk-ID wird auf das zweite, dritte und vierte Oktett einer 127.x.y.z-Loopback-Adresse aufgeteilt. Jeder Dienst erhält einen Offset von slot + 2 (Offsets 0 und 1 sind reserviert).

Offset	Address	Purpose
.0	`127.0.11.0`	Network address (reserved)
.1	`127.0.11.1`	Gateway (reserved)
.2 – .62	`127.0.11.2` – `127.0.11.62`	Services (`slot + 2`)
.63	`127.0.11.63`	Broadcast (reserved)

Beispiel für Netzwerk-ID 2816 (0x0B00), Basisadresse 127.0.11.0:

Dienst	Slot	IP-Adresse
api	0	`127.0.11.2`
postgres	1	`127.0.11.3`
redis	2	`127.0.11.4`

Jedes Repository unterstützt bis zu 61 Dienste (Slots 0 bis 60).

Verwendung von Dienst-IPs in Docker Compose

Da jedes Repository einen isolierten Docker-Daemon ausführt, konfiguriert renet compose automatisch network_mode: host für alle Dienste. Der Kernel schreibt bind()-Aufrufe transparent auf die zugewiesene Loopback-IP des Dienstes um, sodass Dienste an 0.0.0.0 oder localhost binden können ohne Konflikte. Für Verbindungen zu anderen Diensten verwenden Sie den Dienstnamen — renet injiziert jeden Dienstnamen als Hostname, der immer zur richtigen IP auflöst, auch in Forks:

services:
  postgres:
    image: postgres:16
    environment:
      PGDATA: /var/lib/postgresql/data
      POSTGRES_PASSWORD: secret
    # Kein explizites listen_addresses nötig -- der Kernel schreibt bind auf die korrekte Loopback-IP um

  api:
    image: my-api:latest
    environment:
      DATABASE_URL: postgresql://postgres:secret@postgres:5432/mydb  # Dienstnamen verwenden
      LISTEN_ADDR: 0.0.0.0:8080                                      # Kernel schreibt auf Dienst-IP um

Dienstnamen für Verbindungen: Verwenden Sie den Dienstnamen (z. B. postgres, redis) um zu anderen Diensten zu verbinden — renet mappt automatisch jeden Dienstnamen auf seine Loopback-IP via /etc/hosts. ${POSTGRES_IP} in Verbindungsstrings einzubetten, die in Datenbanken oder Konfigurationsdateien gespeichert werden, bäckt die rohe IP ein, was Fork-Isolation bricht und ein Validierungsfehler ist. Die ${SERVICE_IP}-Variablen sind weiterhin für explizite Nutzung verfügbar, aber das Binden wird automatisch vom Kernel übernommen.

Hinweis: Fügen Sie network_mode: host nicht manuell hinzu, renet compose injiziert es automatisch. Restart-Richtlinien (z.B. restart: always) sind sicher zu verwenden, renet entfernt sie automatisch für CRIU-Kompatibilität und der Router-Watchdog übernimmt die Container-Wiederherstellung.

Container-Wiederherstellung und Neustart-Richtlinie

renet und Docker sind absichtlich unterschiedlicher Meinung, wie Container-Neustarts zu behandeln sind. Dieses Verständnis ist wichtig bei der Fehlersuche, warum ein Container (nicht) zurückgekehrt ist.

Übersetzung der Neustart-Richtlinie. Wenn Sie restart: always (oder unless-stopped oder on-failure) in Ihrer Compose-Datei schreiben, entfernt renet diese beim Erstellen des tatsächlichen Compose-Deployments und ersetzt sie durch restart: no. Der ursprüngliche Wert wird in .rediacc.json des Repositories unter services.<name>.restart_policy gespeichert. Dies verhindert, dass Docker’s daemon-seitiger Auto-Restart in CRIU-Checkpoint/Restore eingreift (ein daemon-gesteuerter Neustart würde aus einem veralteten Zustand vor dem Checkpoint fortgesetzt).

Watchdog-Durchsetzung. Der Router-Watchdog läuft periodisch auf jeder Maschine. Bei jedem Tick:

Liest er .rediacc.json für jedes Repository und findet Dienste mit einer wiederherstellbaren restart_policy.
Listet alle Container für den Daemon dieses Repositories auf, identifiziert gestoppte und startet sie gemäß der gespeicherten Richtlinie neu. Eine 30-sekündige Kulanzzeit verhindert Konflikte mit einem Operator, der gerade docker stop ausgeführt hat.
Dieselbe Schleife verarbeitet auch /var/run/rediacc/cold-backup-<guid>.running.json (siehe Cold-Backup-Semantik). Aufgelistete Container werden unabhängig von der gespeicherten Richtlinie neu gestartet, da das Sidecar bedeutet: “renet hat diese Container absichtlich gestoppt und schuldet dem Operator einen Neustart.”

Warum on-failure kaputt wirken kann. Docker’s on-failure-Richtlinie startet nur neu, wenn der Container mit einem Nicht-Null-Code beendet wird. Ein ordnungsgemäßes Stoppen (Exit 0) durch docker stop oder einen Daemon-Shutdown ist kein “Fehler” und löst keinen Neustart aus, weder durch Docker’s native Logik noch durch den gespeicherten Richtlinienpfad des Watchdogs. Das Cold-Backup-Sidecar ist das Sicherheitsnetz: Jeder Container, den wir absichtlich gestoppt haben, wird unabhängig von seiner Richtlinie neu gestartet.

Laufzeitzustand interpretieren:

docker inspect <container> → RestartPolicy.Name: wird für renet-verwaltete Container immer no sein. Verlassen Sie sich nicht darauf für die semantische Richtlinie.
.rediacc.json im Repository-Mount-Root → services.<name>.restart_policy: die eigentliche Absicht.
docker ps --format '{{.Status}}': Laufzeitzustand.

Abweichung beheben. Wenn die in .rediacc.json gespeicherte Richtlinie eines Containers falsch ist (z. B. weil Sie Compose bearbeitet, den Container aber nie neu erstellt haben), führen Sie rdc repo up --name <repo> -m <machine> erneut aus. Der Container wird mit der aktualisierten gespeicherten Richtlinie neu erstellt.

Experimentell: Die Cold-Backup-Sidecar-basierte Wiederherstellung und das Flag --sync-certs bei rdc machine query wurden in renet 0.9+ eingeführt. Ältere Versionen verlassen sich ausschließlich auf die gespeicherte restart_policy für Watchdog-Wiederherstellung, was on-failure-Container nach einem Cold-Backup hängen lassen kann.

Docker-Bridge-Networking ist für rediacc-verwaltete Daemons deaktiviert. Jeder pro-Repo-Daemon ist mit "bridge": "none" und "iptables": false konfiguriert. Ein einfaches docker run <image> innerhalb einer Repository-Shell startet zwar, aber der Container erhält lediglich ein Loopback-Interface und verfügt weder über DNS noch über ausgehende Konnektivität. Dies ist beabsichtigt, da die Loopback-Isolation zwischen Repos durch eBPF-cgroup-Hooks erzwungen wird, die ein Bridged-Container umgehen würde. Produktionsdienste sollten renet compose verwenden (das Host-Networking für Sie injiziert); für Ad-hoc-Debugging übergeben Sie --network host explizit: docker run --rm --network host -it ubuntu bash.

Hinweis: Fork-Repos erhalten Auto-Routen unter der Subdomain des Eltern-Repos: {service}-fork-{tag}.{repo}.{machine}.{baseDomain}. Benutzerdefinierte Domains werden bei Forks übersprungen.

Dienste starten

Repository einbinden und alle Dienste starten:

rdc repo up --name my-app -m server-1

CLI-Referenz: rdc repo up

Option	Beschreibung
`--skip-router-restart`	Route-Server-Neustart nach der Operation überspringen

Die Ausführungssequenz ist:

Das LUKS-verschlüsselte Repository einbinden (automatisch, wenn nicht eingebunden)
Den isolierten Docker-Daemon starten
.rediacc.json automatisch aus Compose-Dateien generieren
up() in allen Rediaccfiles ausführen (A-Z-Reihenfolge)

Nach der Bereitstellung zeigt die Ausgabe einen PROXY ROUTES-Abschnitt mit den tatsächlichen URLs für jeden Dienst. Dienste mit benutzerdefinierten Traefik-Labels zeigen ihre benutzerdefinierten Domains als primäre URLs:

HTTP services (accessible via proxy after ~3s):
  gitlab-server:
    HTTPS: https://gitlab.example.com  (custom)
    Auto:  https://gitlab-server.gitlab.server-1.example.com
    IP:    127.0.11.130

Dienste stoppen

rdc repo down --name my-app -m server-1

CLI-Referenz: rdc repo down

Option	Beschreibung
`--unmount`	Das verschlüsselte Repository nach dem Stoppen aushängen. Falls dies nicht wirksam wird, verwenden Sie `rdc repo unmount` separat.
`--skip-router-restart`	Route-Server-Neustart nach der Operation überspringen

Die Ausführungssequenz ist:

down() in allen Rediaccfiles ausführen (Z-A umgekehrte Reihenfolge, Best-Effort)
Den isolierten Docker-Daemon stoppen (wenn --unmount)
Das LUKS-verschlüsselte Volume aushängen und schließen (wenn --unmount)

Massenoperationen

Alle Repositories auf einer Maschine gleichzeitig starten oder stoppen:

rdc repo up -m server-1

CLI-Referenz: rdc repo up

Option	Beschreibung
`--include-forks`	Geforkte Repositories einschließen
`--mount-only`	Nur einbinden, keine Container starten
`--dry-run`	Anzeigen, was ausgeführt würde
`--parallel`	Operationen parallel ausführen
`--concurrency <n>`	Maximale parallele Operationen (Standard: 3)
`--skip-router-restart`	Route-Server-Neustart nach der Operation überspringen

Autostart beim Hochfahren

Standardmäßig müssen Repositories nach einem Server-Neustart manuell eingebunden und gestartet werden. Autostart konfiguriert Repositories so, dass sie beim Hochfahren des Servers automatisch eingebunden werden, Docker gestartet und das Rediaccfile up() ausgeführt wird.

Funktionsweise

Wenn Sie Autostart für ein Repository aktivieren:

Wird eine 256 Byte große zufällige LUKS-Schlüsseldatei generiert und dem LUKS-Slot 1 des Repositories hinzugefügt (Slot 0 bleibt die Benutzer-Passphrase)
Die Schlüsseldatei wird unter {datastore}/.credentials/keys/{guid}.key mit 0600-Berechtigungen (nur Root) gespeichert
Ein systemd-Dienst (rediacc-autostart) wird beim Hochfahren ausgeführt, um alle aktivierten Repositories einzubinden und deren Dienste zu starten

Beim Herunterfahren stoppt der Dienst ordnungsgemäß alle Dienste (Rediaccfile down()), stoppt Docker-Daemons und schließt LUKS-Volumes.

Sicherheitshinweis: Das Aktivieren von Autostart speichert eine LUKS-Schlüsseldatei auf der Festplatte des Servers. Jeder mit Root-Zugriff auf den Server kann das Repository ohne Passphrase einbinden. Bewerten Sie dies basierend auf Ihrem Bedrohungsmodell.

Aktivieren

rdc repo autostart enable --name my-app -m server-1

CLI-Referenz: rdc repo autostart enable

Sie werden nach der Repository-Passphrase gefragt.

Alle aktivieren

rdc repo autostart enable -m server-1

CLI-Referenz: rdc repo autostart enable

Deaktivieren

rdc repo autostart disable --name my-app -m server-1

CLI-Referenz: rdc repo autostart disable

Dies entfernt die Schlüsseldatei und löscht LUKS-Slot 1.

Schlüsseldatei-Aktualisierung beim Deployment

Wenn Autostart aktiviert ist, validiert rdc repo up die LUKS-Slot-1-Schlüsseldatei. Falls die auf der Festplatte gespeicherte Schlüsseldatei noch mit dem LUKS-Slot übereinstimmt, werden keine Änderungen vorgenommen.

Nach der Übertragung eines Repositories zwischen Maschinen via repo push / repo pull stimmt die Schlüsseldatei auf der neuen Maschine nicht überein. In diesem Fall regeneriert repo up automatisch die Schlüsseldatei und aktualisiert LUKS-Slot 1. Sie sehen folgende Log-Meldungen:

Refreshing keyfile credential for <guid>
Killing LUKS slot 1: /mnt/rediacc/repositories/<guid>
Adding keyfile to LUKS slot 1: /mnt/rediacc/repositories/<guid>

Dies ist sicher — Slot 0 (Ihre Passphrase) wird nie geändert. Wenn Autostart nicht aktiviert ist, wird die Prüfung stillschweigend übersprungen. Fehler sind nicht-kritisch und blockieren das Deployment nicht.

Status anzeigen

rdc repo autostart list -m server-1

CLI-Referenz: rdc repo autostart list

Vollständiges Beispiel

Dieses Beispiel stellt eine Webanwendung mit PostgreSQL, Redis und einem API-Server bereit.

1. Einrichten

curl -fsSL https://www.rediacc.com/install.sh | bash
rdc config init --name production --ssh-key ~/.ssh/id_ed25519
rdc config machine add --name prod-1 --ip 203.0.113.50 --user deploy
rdc config machine setup --name prod-1
rdc repo create --name webapp -m prod-1 --size 10G

CLI-Referenz: rdc config init · rdc config machine add · rdc config machine setup · rdc repo create

2. Einbinden und vorbereiten

rdc repo mount --name webapp -m prod-1

CLI-Referenz: rdc repo mount

3. Anwendungsdateien erstellen

Erstellen Sie innerhalb des Repositories die folgenden Dateien:

docker-compose.yml:

services:
  postgres:
    image: postgres:16
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: webapp
      POSTGRES_USER: app
      POSTGRES_PASSWORD: changeme

  redis:
    image: redis:7-alpine

  api:
    image: myregistry/api:latest
    environment:
      DATABASE_URL: postgresql://app:changeme@postgres:5432/webapp
      REDIS_URL: redis://redis:6379
      LISTEN_ADDR: 0.0.0.0:8080

Rediaccfile:

#!/bin/bash

up() {
    mkdir -p data/postgres
    renet compose -- up -d

    echo "Waiting for PostgreSQL..."
    for i in $(seq 1 30); do
        if renet compose -- exec postgres pg_isready -q 2>/dev/null; then
            echo "PostgreSQL is ready."
            return 0
        fi
        sleep 1
    done
    echo "Warning: PostgreSQL did not become ready within 30 seconds."
}

down() {
    renet compose -- down
}

4. Starten

rdc repo up --name webapp -m prod-1

CLI-Referenz: rdc repo up

5. Autostart aktivieren

rdc repo autostart enable --name webapp -m prod-1

CLI-Referenz: rdc repo autostart enable