Démarrer avec Docker Compose

Le dépôt livre une stack Compose sous deploy/compose/ : un déploiement nœud unique durci (SQLite embarqué, zéro dépendance externe) plus deux overlays — un override Postgres multi-tenant et un profil de sauvegarde de reprise après sinistre. Ce tutoriel vous mène de up -d à un control plane configuré avec des sauvegardes.

Le conteneur enveloppe le même binaire unique que toute autre installation ; seul l’emballage diffère. Les commandes ci-dessous sont les points d’entrée documentés de la stack elle-même (deploy/compose/*.yml), et le flux de premier démarrage qu’elles pilotent est le même que celui vérifié de bout en bout contre le binaire dans le tutoriel nœud unique.

Olivares 0.4

La prochaine version est 0.4 ; sa release GitHub n’est pas encore publiée. Les commandes ci-dessous décrivent les artefacts prévus. Compilez depuis les sources jusqu’à la publication, puis vérifiez chaque artefact avant utilisation. L’état observé figure dans docs/releases/0.4-install-surfaces.json.

1. Démarrer la stack nœud unique (SQLite)

1. Démarrez-la :

   Si AppArmor contrôle la création des espaces de noms utilisateur, suis « Session confinement on AppArmor hosts » dans deploy/compose/README.md sur l’hôte du daemon Docker avant de démarrer la pile.

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

   Ce que vous obtenez, par conception :

   Propriété	Valeur
   Ports	8443 (HTTPS : REST + interface web), 8444 (gRPC) — publiés sur toutes les interfaces de l’hôte, car c’est un serveur. Mettez OLIVARES_BIND=127.0.0.1 dans .env pour les restreindre à l’hôte
   Données	volume nommé olivares-data → /var/lib/olivares (store SQLite, clé de signature d’audit, matériel TLS)
   Durcissement	tourne en 65532:65532, racine en lecture seule, toutes les capabilities supprimées, no-new-privileges, tmpfs /tmp
   Healthcheck	exécution directe de la commande intégrée olivares readyz — sans shell, curl ni wget. Seul un HTTP 200 de /readyz local est sain

2. Demandez au moteur où il est, et lisez le jeton de configuration à usage unique depuis les journaux :

   # 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. Créez le premier administrateur, connectez-vous, et créez votre organisation — exactement comme dans le tutoriel nœud unique (l’API est la même ; le certificat TLS est auto-signé au premier démarrage, donc curl -k pour le bootstrap) :

   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>"}'

Contrat actuel et qualification hébergée

Contrat de disponibilité de Compose. Des fixtures HTTP/TLS locales et hermétiques prouvent les trois réponses de la sonde : 200 → rc 0, une réponse non-200 reçue → rc 1, et un échec d’entrée, TLS ou transport → rc 2. La qualification Docker reste non mesurée jusqu’à la réussite du workflow lancé manuellement pour ce commit ; la présence d’un workflow dans le dépôt ne prouve pas que son exécution Docker a eu lieu.

Jeton manqué ?

Un redémarrage ne le réaffiche pas (seul son hash est stocké). Tant qu’aucun administrateur n’existe, émettez-en un de remplacement sans rien redémarrer — le moteur en cours l’accepte immédiatement et le jeton précédent cesse de fonctionner :

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

Les quatre commandes, et pourquoi chacune a besoin du `-f`

La stack nomme son propre projet Compose : le conteneur du moteur est donc olivares (et non compose-olivares-1) et les services des overrides sont olivares-postgres-1 et olivares-backup-1. Compose cherche toujours un fichier compose dans le répertoire courant, et celui-ci vit dans deploy/compose/ — un simple docker compose ps à la racine du dépôt répond donc “no configuration file provided”. Passez -f à chaque fois, ou faites export COMPOSE_FILE=deploy/compose/docker-compose.yml une seule fois.

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 est la voie du binaire local, pas celle-ci : ici le serveur tourne déjà — la commande du conteneur est serve — et quickstart lancerait un second moteur dans le conteneur.

2. Câbler les sources

Les sources sont déclarées dans un seul fichier opérateur nommé par OLIVARES_SOURCES_CONFIG (connecter une source). Pour le conteneur, montez le fichier et définissez la variable avec un petit 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"

Rappelez-vous que les chemins à l’intérieur de sources.json sont des chemins conteneur — une traînée de journal pgAudit, par exemple, nécessite que le répertoire de journaux Postgres soit monté en lecture seule dans le conteneur également.

3. Sauvegardes DR chiffrées (le profil backup)

La stack livre un service de sauvegarde one-shot qui produit un bundle chiffré et sûr pour la continuité du ledger (olivares dr backup) :

Conservez la phrase secrète dans un fichier privé hors du dépôt et de l’image, et gardez une copie en lieu sûr hors de cet hôte : sans elle, aucun bundle ne peut être restauré. Donnez au conteneur de sauvegarde un accès en lecture seule à ce fichier (l’image s’exécute avec l’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

Enveloppez cette commande dans un cron de l’hôte pour un RPO planifié, et mettez en miroir le volume olivares-backups hors site — une sauvegarde sur le même hôte n’est pas une reprise après sinistre, et la passphrase doit voyager séparément des bundles (3-2-1). La procédure complète, y compris l’exercice de restauration (olivares dr verify), est dans sauvegarde & restauration.

4. Optionnel : l’override Postgres multi-tenant

Pour la topologie multi-tenant, superposez l’override Postgres. Il démarre un Postgres 16, provisionne le rôle olivares_app à moindre privilège (pas de superuser, pas de BYPASSRLS — le moteur refuse de démarrer contre un rôle privilégié, car la sécurité au niveau ligne est le filet de sécurité du tenant), et y pointe le moteur :

L’override provisionne aussi olivares_admin, un rôle distinct NOSUPERUSER BYPASSRLS avec un accès en lecture seule aux tables du moteur. Le moteur l’utilise via --admin-dsn pour les lectures entre locataires, y compris lors de la configuration initiale.

Définissez d’abord trois mots de passe distincts, en utilisant uniquement A-Z a-z 0-9 . _ ~ - pour cette démo Compose, puis montez la stack :

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

Le Postgres compose est une topologie de démonstration

L’override se connecte avec sslmode=disable à l’intérieur du réseau compose — acceptable pour l’évaluation, pas pour la production. Un déploiement Postgres de production utilise TLS avec sslmode=verify-full et un secret DSN — c’est la voie Kubernetes/Helm.

Santé

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

Étapes suivantes

• Câbler de vrais signaux : les guides de connecteurs.
• Planifier et exercer les sauvegardes : sauvegarde & restauration.
• Le superviser : métriques Prometheus, SLO et alertes.
• Passer en multi-nœuds ? Kubernetes avec Helm, y compris la HA et le DaemonSet des collecteurs.