Mit Docker Compose loslegen

Das Repository liefert einen Compose-Stack unter deploy/compose/: ein gehärtetes Single-Node-Deployment (eingebettetes SQLite, null externe Abhängigkeiten) plus zwei Overlays — ein Postgres-Multi-Tenant-Override und ein Disaster-Recovery-Backup-Profil. Dieses Tutorial führt Sie von up -d zu einer konfigurierten Control Plane mit Backups.

Der Container umhüllt das gleiche einzelne Binary wie jede andere Installation; nur das Packaging unterscheidet sich. Die untenstehenden Befehle sind die eigenen dokumentierten Einstiegspunkte des Stacks (deploy/compose/*.yml), und der Erststart-Ablauf, den sie steuern, ist derselbe, der im Single-Node-Tutorial end-to-end gegen das Binary verifiziert wird.

Olivares 0.4

Das nächste Release ist 0.4; es ist noch nicht auf GitHub veröffentlicht. Die folgenden Befehle beschreiben die geplanten Artefakte. Bauen Sie bis zur Veröffentlichung aus dem Quellcode und prüfen Sie danach jedes Artefakt vor der Verwendung. Der beobachtete Veröffentlichungsstand steht in docs/releases/0.4-install-surfaces.json.

1. Den Single-Node-Stack hochfahren (SQLite)

1. Starten Sie ihn:

   Wenn AppArmor auf dem Host die Erstellung von Benutzer-Namespaces kontrolliert, führe vor dem Start auf dem Host des Docker-Daemons die Schritte unter “Session confinement on AppArmor hosts” in deploy/compose/README.md aus.

   docker compose -f deploy/compose/docker-compose.yml up --wait --wait-timeout 120

   Was Sie erhalten, by design:

   Eigenschaft	Wert
   Ports	8443 (HTTPS: REST + Web-UI), 8444 (gRPC) — veröffentlicht auf allen Host-Schnittstellen, denn dies ist ein Server. Setzen Sie OLIVARES_BIND=127.0.0.1 in .env, um sie auf den Host zu beschränken
   Daten	benanntes Volume olivares-data → /var/lib/olivares (SQLite-Store, Audit-Signaturschlüssel, TLS-Material)
   Hardening	läuft als 65532:65532, read-only root, alle Capabilities entfernt, no-new-privileges, tmpfs /tmp
   Healthcheck	direkter Aufruf des eingebauten olivares readyz—ohne Shell, curl oder wget. Nur HTTP 200 vom lokalen /readyz ist gesund

2. Fragen Sie die Engine, wo sie ist, und lesen Sie das einmalige Setup-Token aus den Logs:

   # where the console answers, and whether setup is still pending. It runs the binary
   # directly and needs no shell.
   docker compose -f deploy/compose/docker-compose.yml exec olivares olivares first-boot
   
   # the one-time setup token, printed once at first boot
   docker compose -f deploy/compose/docker-compose.yml logs olivares \
     | sed -n '/FIRST-BOOT SETUP/,/========================/p'

3. Erstellen Sie den ersten Administrator, melden Sie sich an und erstellen Sie Ihre Organisation — genau wie im Single-Node-Tutorial (die API ist dieselbe; das TLS-Zertifikat ist beim ersten Boot selbstsigniert, also curl -k für das Bootstrapping):

   curl -ksf -X POST https://localhost:8443/v1/setup \
     -H 'Content-Type: application/json' \
     -d '{"token":"<olst_ token>","email":"you@example.com","password":"<strong-password>"}'

Aktueller Vertrag und gehostete Qualifikation

Compose-Readiness-Vertrag. Hermetische lokale HTTP-/TLS-Fixtures belegen die drei Antworten der Probe: 200 → rc 0, empfangenes Nicht-200 → rc 1 und ein Eingabe-, TLS- oder Transportfehler → rc 2. Die Docker-Qualifikation bleibt ungemessen, bis der Dispatch-Workflow für diesen Commit erfolgreich ist; ein eingecheckter Workflow ist kein Beleg, dass sein Docker-Lauf stattgefunden hat.

Token verpasst?

Ein Neustart gibt es nicht erneut aus (nur sein Hash wird gespeichert). Solange kein Administrator existiert, erzeugen Sie ohne Neustart ein Ersatz-Token — die laufende Engine akzeptiert es sofort, und das vorherige Token funktioniert nicht mehr:

docker compose -f deploy/compose/docker-compose.yml exec olivares \
  olivares first-boot --new-token

Die vier Befehle, und warum jeder das `-f` braucht

Der Stack benennt sein eigenes Compose-Projekt, daher heißt der Container der Engine olivares (nicht compose-olivares-1) und die Dienste der Overrides olivares-postgres-1 und olivares-backup-1. Compose sucht die Compose-Datei weiterhin im Arbeitsverzeichnis, und diese liegt in deploy/compose/ — ein bloßes docker compose ps im Repository-Wurzel antwortet also “no configuration file provided”. Geben Sie -f jedes Mal an, oder einmal export COMPOSE_FILE=deploy/compose/docker-compose.yml.

docker compose -f deploy/compose/docker-compose.yml exec olivares olivares first-boot
docker compose -f deploy/compose/docker-compose.yml logs olivares
docker compose -f deploy/compose/docker-compose.yml ps
docker compose -f deploy/compose/docker-compose.yml down

olivares quickstart ist der Weg über das lokale Binary, nicht dieser: hier läuft der Server bereits — der Container-Befehl ist serve — und quickstart würde eine zweite Engine im Container starten.

2. Quellen verdrahten

Quellen werden in einer einzigen Operator-Datei deklariert, die durch OLIVARES_SOURCES_CONFIG benannt wird (Eine Quelle anbinden). Für den Container mounten Sie die Datei und setzen die Variable mit einem kleinen Override:

# deploy/compose/docker-compose.sources.yml (yours — not shipped)
services:
  olivares:
    environment:
      OLIVARES_SOURCES_CONFIG: /etc/olivares/sources.json
    volumes:
      - ./sources.json:/etc/olivares/sources.json:ro

docker compose -f deploy/compose/docker-compose.yml \
               -f deploy/compose/docker-compose.sources.yml up -d
docker compose -f deploy/compose/docker-compose.yml logs olivares | grep "ingest: wired source"

Denken Sie daran, dass die Pfade innerhalb von sources.json Container-Pfade sind — ein pgAudit-Log-Tail zum Beispiel benötigt das Postgres-Log-Verzeichnis ebenfalls read-only in den Container gemountet.

3. Verschlüsselte DR-Backups (das backup-Profil)

Der Stack liefert einen One-Shot-Backup-Service, der ein verschlüsseltes, ledger-kontinuitäts-sicheres Bundle erzeugt (olivares dr backup):

Bewahren Sie die Passphrase in einer privaten Datei außerhalb des Checkouts und des Images auf und halten Sie eine Kopie an einem sicheren Ort außerhalb dieses Hosts vor: Ohne sie lässt sich kein Bundle wiederherstellen. Geben Sie dem Backup-Container schreibgeschützten Zugriff darauf (das Image läuft mit UID 65532):

sudo install -d -o 65532 -g 65532 -m 0700 /srv/olivares-dr
sudo install -o 65532 -g 65532 -m 0400 /path/to/private-passphrase /srv/olivares-dr/dr-pass

BACKUP_TS="$(date -u +%Y%m%dT%H%M%SZ)" \
docker compose -f deploy/compose/docker-compose.yml \
               -f deploy/compose/docker-compose.backup.yml \
               -f - --profile backup run --rm backup <<'YAML'
services:
  backup:
    volumes:
      - /srv/olivares-dr/dr-pass:/run/secrets/dr-pass:ro
YAML

Verpacken Sie diesen Befehl in einen Host-Cron für eine geplante RPO und spiegeln Sie das Volume olivares-backups offsite — ein Backup auf demselben Host ist keine Disaster Recovery, und die Passphrase muss getrennt von den Bundles reisen (3-2-1). Die vollständige Prozedur, einschließlich des Restore-Drills (olivares dr verify), steht in Backup & Restore.

4. Optional: das Postgres-Multi-Tenant-Override

Für die Multi-Tenant-Topologie legen Sie das Postgres-Override darüber. Es fährt ein Postgres 16 hoch, stellt die least-privilege-Rolle olivares_app bereit (kein Superuser, kein BYPASSRLS — die Engine verweigert den Start gegen eine privilegierte Rolle, weil Row-Level-Security der Mandanten-Backstop ist) und richtet die Engine darauf aus:

Das Override stellt außerdem olivares_admin bereit, eine separate Rolle mit NOSUPERUSER BYPASSRLS und ausschließlich Lesezugriff auf die Engine-Tabellen. Die Engine verwendet sie über --admin-dsn für mandantenübergreifende Lesezugriffe, auch bei der Ersteinrichtung.

Setzen Sie zuerst drei unterschiedliche Passwörter. Verwenden Sie für diese Compose-Demo nur A-Z a-z 0-9 . _ ~ -, dann fahren Sie den Stack hoch:

cp deploy/compose/.env.example deploy/compose/.env
# set three distinct passwords in deploy/compose/.env:
# POSTGRES_SUPERUSER_PASSWORD, OLIVARES_DB_PASSWORD, OLIVARES_ADMIN_PASSWORD

docker compose -f deploy/compose/docker-compose.yml \
               -f deploy/compose/docker-compose.postgres.yml up -d

Das Compose-Postgres ist eine Demo-Topologie

Das Override verbindet sich mit sslmode=disable innerhalb des Compose-Netzwerks — in Ordnung für die Evaluierung, nicht für die Produktion. Ein Produktiv-Postgres-Deployment verwendet TLS mit sslmode=verify-full und ein DSN-Secret — das ist der Kubernetes/Helm-Pfad.

Health

curl -ks https://localhost:8443/readyz
# {"leader":true,"setup_required":false,"status":"ok","store":"up"}
curl -ks https://localhost:8443/metrics | grep olivares_store_up

Nächste Schritte

• Echte Signale verdrahten: die Connector-Anleitungen.
• Backups planen und drillen: Backup & Restore.
• Es überwachen: Prometheus-Metriken, SLOs und Alerts.
• Multi-Node? Kubernetes mit Helm, einschließlich HA und dem Collectors-DaemonSet.