CLI de l'image

L'image sait déjà se lancer toute seule : inutile d'ajouter une commande à docker run, par défaut c'est le serveur qui démarre. Un argument ne remplace que la commande, si bien qu'une opération ponctuelle se lit tout naturellement — docker run … IMAGE restore.

Dans un conteneur en marche, les commandes d'opérateur s'appellent via docker exec, sous des noms courts :

docker exec notarium backup
docker exec -it notarium admin list

Commandes

start reste au premier plan, et les signaux du conteneur atteignent donc directement le serveur — docker stop l'arrête proprement. Il n'existe volontairement aucune commande d'arrêt ni de redémarrage : c'est l'affaire de l'orchestrateur. Les migrations de schéma s'appliquent au démarrage ; vous n'avez jamais à les lancer par une commande à part.

Flux et codes de sortie

• En mode flux (sans --output), backup n'envoie sur stdout que les octets du ZIP ; les diagnostics et le récapitulatif final partent sur stderr. Avec --output FILE, l'archive est écrite dans ce fichier et un unique récapitulatif JSON part sur stdout — ne le redirigez pas vers un .zip, ce qui atterrirait là ne serait pas une archive.
• backup verify, restore et les commandes admin non interactives impriment leur résultat sur stdout.
• Les erreurs partent sur stderr et renvoient un code non nul. Les commandes inconnues, les options inconnues, les options répétées et les options sans valeur échouent au lieu d'être ignorées en silence.
• Le transport canonique sous Docker, ce sont stdin et stdout. Les options jumelles --output FILE de backup et --input FILE de verify/restore existent pour les cas où le conteneur voit déjà le répertoire. --output a un effet de bord bienvenu : la commande écrit elle-même dans un fichier temporaire, vérifie l'archive et la publie de façon atomique sans rien écraser — il n'y a donc aucune enveloppe shell à écrire.
• Chaque commande dispose de --help ; notarium --version équivaut à notarium version.

Identité du build

version affiche exactement ce que vous faites tourner — c'est le point de départ de toute discussion sur la compatibilité et de toute mise à niveau :

docker run --rm docouno/notarium:latest version
docker compose exec notarium version --json

version --json renvoie la même chose en un seul objet — version, commit, builtAt et source (un lien vers la révision exacte des sources) —, si bien que le contrôle « qu'est-ce qui est déployé ? » peut aller directement dans votre pipeline de déploiement. Ce que le build n'a honnêtement pas est renvoyé comme null : les valeurs ne sont jamais inventées, vous pouvez donc vous appuyer dessus. La même information figure dans l'interface — Settings → About.

Health checks

healthcheck ne renvoie un code de sortie nul que lorsque l'endpoint local /api/health se déclare en bonne santé. Il est conçu pour la directive HEALTHCHECK de Docker et pour les sondes de l'orchestrateur — aucune dépendance externe, et pas besoin de curl sur l'hôte.

Récupérer l'accès

admin est la frontière opérateur de l'hôte. Les moyens ordinaires de changer un mot de passe vivent tous dans l'application (le vôtre depuis l'interface, celui d'un autre par un lien à usage unique émis par un administrateur). La CLI, elle, sert à autre chose : forcer un mot de passe sans présenter l'actuel, et émettre un administrateur hors bande. Pour ces deux opérations, il n'existe volontairement aucune route HTTP — il n'y a rien à présenter —, et elles reviennent donc à celui qui a accès à l'hôte.

docker compose exec notarium admin list
docker compose exec notarium admin create-admin <user> --random

La liste complète des commandes et le sens de chacune : Authentification.

Ensuite

• Sauvegarde et restauration — le runbook derrière backup, backup verify et restore.
• Authentification — ce que sait faire admin et quand il devient nécessaire.
• Installation — lancer l'image et le volume de données.