Aller au contenu
mcpd
aucun daemon
Source

Installation

mcpd est un binaire unique avec le stockage compilé dedans, si bien que l’installer revient à poser ce binaire quelque part et à le lancer. Prenez la voie ci-dessous qui correspond le mieux à votre façon de faire tourner les choses.

Docker

Aucune version publiée pour l'instant.

L'image, le chart et les paquets que nomment les commandes de ce site sont la distribution prévue. Aucun n'est publié. Ce qui fonctionne aujourd'hui est une compilation depuis les sources, qui demande Rust et Node :

Compiler et lancer

git clone https://github.com/mcpd/mcpd && cd mcpd && make build && ./target/release/mcpd demo

L’image publiée est la voie la plus courte, et celle que suppose le reste de la documentation.

docker run -p 4317:4317 -v mcpd-data:/data -e MCPD_DATA=/data/mcpd.db ghcr.io/mcpd/mcpd

Le volume compte. mcpd écrit une base SQLite au chemin que nomme MCPD_DATA, et un conteneur sans volume emporte vos traces quand il s’arrête. Nommer le chemin explicitement coûte un indicateur et retire la question de savoir où le fichier est passé.

Chaque indicateur a une variable d’environnement, donc tout ce que vous pouvez passer en ligne de commande, vous pouvez aussi le régler avec -e. Fixez un tag plutôt que de suivre latest dans tout ce qui compte pour vous. L’image est construite pour linux/amd64 et linux/arm64, et Docker récupère celle qui correspond à votre machine.

Docker Compose

Le même conteneur, mis par écrit. C’est la forme à prendre quand mcpd est posé à côté de votre application sur un seul hôte.

compose.yaml
services:
  mcpd:
    image: ghcr.io/mcpd/mcpd:latest
    restart: unless-stopped
    ports:
      - "4317:4317"
    volumes:
      - mcpd-data:/data
    environment:
      MCPD_DATA: /data/mcpd.db
      MCPD_PROJECT: default
      # À définir avant que ce port ne soit joignable par quelqu’un d’autre.
      # MCPD_INGEST_KEYS: key-for-your-agents
      # MCPD_READ_KEYS: key-for-your-team
      # MCPD_RETENTION_DAYS: 30

volumes:
  mcpd-data:

Les trois clés commentées sont celles à remplir avant que ceci n’atteigne un réseau où se trouve quelqu’un d’autre. Sans aucune clé définie, l’ingestion et les lectures sont ouvertes toutes les deux, ce qui est correct sur votre portable et faux partout ailleurs. Déploiement indique ce qu’il faut régler et pourquoi.

Kubernetes

Chaque version pousse le chart dans le même registre que l’image, comme artefact OCI, il n’y a donc pas de dépôt à ajouter d’abord. Le chart refuse de s’installer sans une clé d’ingestion et une clé de lecture, alors générez les deux d’abord.

helm install mcpd oci://ghcr.io/mcpd/charts/mcpd -n mcpd --create-namespace --set keys.ingest=$INGEST_KEY --set keys.read=$READ_KEY

mcpd traite SIGTERM et s’arrête proprement, et c’est ce que Kubernetes envoie. Il expose /healthz pour la sonde de vivacité et /readyz pour la sonde de disponibilité, et les deux diffèrent à dessein : la vivacité ne touche jamais au stockage, si bien qu’une base lente ne peut pas faire redémarrer le pod en boucle. Les valeurs, les sondes et la forme du Deployment sont sur Docker et Kubernetes.

Un binaire de version publiée

Chaque version joint une archive pour Linux sur x86_64 et arm64, statique et compilée contre musl, si bien qu’il n’y a pas de libc à faire correspondre, et pour macOS sur Apple silicon et Intel. Un fichier SHA256SUMS et une attestation de provenance de compilation les accompagnent. Décompressez l’archive de votre machine et lancez ./mcpd ; sans argument, il démarre le daemon.

Il n’y a pas de cargo install mcpd. Rien n’est publié sur crates.io, et une crate compilée depuis le registre ne pourrait pas porter l’interface, qui est construite avec npm et compilée dans le binaire. Avec une chaîne d’outils Rust, compilez plutôt depuis les sources.

Depuis les sources

Clonez le dépôt et lancez la compilation de distribution. Elle emploie l’optimisation complète à l’édition de liens et une seule unité de génération de code, ce qui compile plus lentement et produit le binaire le plus petit et le plus rapide. Passez par make plutôt que par cargo directement : l’interface est compilée dans le binaire, et make dist la construit d’abord, ce qu’un simple cargo build sur un clone tout neuf n’a aucun moyen de faire. Cette étape demande Node et npm sur la machine, en plus de la chaîne d’outils Rust.

git clone https://github.com/mcpd/mcpd && cd mcpd && make dist

Le binaire est écrit dans target/dist/mcpd, ou target/release/mcpd si vous avez pris la voie rapide. Utilisez make build pendant que vous travaillez sur mcpd lui-même, et make dist pour tout ce que vous comptez faire tourner.

Où vont les données

--data est le chemin du fichier SQLite, et il vaut ./mcpd.db par défaut, dans le répertoire de travail. Les répertoires parents sont créés pour vous.

Passer :memory: garde tout en mémoire et n’écrit rien sur le disque. C’est le bon choix pour une suite de tests, pour une démonstration sur la machine de quelqu’un d’autre, et pour toute exécution dont vous préférez ne pas laisser traîner les prompts. Le stockage disparaît avec le processus, et c’est le but.

Ne rien laisser derrière

mcpd --data :memory:

mcpd demo remplit le stockage avec une exécution en échec réaliste puis se met à servir, si bien que l’interface a quelque chose dedans la première fois que vous l’ouvrez.

Vérifiez ce qu’il fera avant de le lancer

mcpd config affiche la configuration à laquelle cette invocation aboutit, puis s’arrête. Indicateurs, variables d’environnement et valeurs par défaut finissent dans un seul relevé : vous voyez laquelle l’a emporté sans rien démarrer.

configuration résolue
$ mcpd configlisten          0.0.0.0:4317storage         sqlite at ./mcpd.dbconfig file     nonelog format      textproject         defaultprojects        noneretention       foreveringest auth     openread auth       openwrite auth      openadmin auth      openexecute auth    openworker auth     opensignup          offruns            sqlite at ./mcpd.runs.dbrun settings    lease_ttl_ms 30000, reclaim_window_ms 30000, stall_window_ms 300000, idempotency_window_ms 86400000, park_ttl_ms 86400000, max_depth 8, max_step_repeats 16identity        offclient ip       peer addresssampling        keep everythingquota           unlimitedredaction       onredact key      built in, which is public; set --redact-keycors            same-origin onlytimeout         30s per requestlimits          32 MiB per request, 10000 signals per batchderived         duration and token metricsaspects         offmonitors        noneobjectives      nonejudge           offforwarding      off

Vérifiez l’installation

/healthz répond à la question de savoir s’il tourne vraiment. Il ne lit jamais le stockage, donc il reste rapide et reste honnête sur le processus plutôt que sur le disque.

vérification
$ curl -s localhost:4317/healthz{"status":"ok","version":"0.1.0","spec_version":"1.0.0","uptime_seconds":8,"storage":"sqlite"}$ curl -s -o /dev/null -w "%{http_code}\n" localhost:4317/readyz200

spec_version est la version du modèle de données que cette compilation met en œuvre. Un client peut la lire et refuser de parler à un serveur qu’il ne comprend pas, ce qui vaut mieux qu’envoyer un lot qui sera rejeté champ par champ.

/readyz est l’autre moitié. Il interroge le stockage et répond 503 quand le stockage est injoignable, si bien qu’un répartiteur de charge cesse d’envoyer des lectures à une instance qui ne peut pas les servir. Prenez /healthz pour la vivacité et /readyz pour la disponibilité, jamais le même pour les deux.

Ouvrez ensuite localhost:4317 et vous avez l’interface sous les yeux.

Ensuite

  • Envoyez-lui une trace depuis votre propre agent : Prise en main.
  • Apprenez les mots qu’emploie le reste de la documentation : Concepts.
  • Chaque indicateur et variable d’environnement dans un seul tableau : Configuration.
  • Avant que quelqu’un d’autre puisse atteindre le port : Docker et Kubernetes.