Faire tourner mini-me dans un conteneur

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117

# Faire tourner mini-me dans un conteneur

`mm dockerinit` écrit un `Dockerfile` et un `compose.yaml` dans le dossier courant. L'image contient la dernière version publiée de `mm` et les outils de son outil `bash` ; compose monte votre projet et lance l'agent avec votre utilisateur, pas en root.

Pour les microVM de Docker plutôt qu'un simple conteneur, voir [faire tourner mini-me dans un Docker Sandbox](run-in-a-docker-sandbox.md).

## Avant de commencer

- Docker avec Compose.
- Un fichier d'agent dans le projet. Si vous n'en avez pas, lancez d'abord `mm init` (voir [créer un agent](create-an-agent.md)).
- Un serveur de modèles sur votre machine, joignable depuis le conteneur : voir [Joindre le modèle](#joindre-le-modèle).

## Écrire les fichiers

Dans le dossier de votre projet :

```bash
mm dockerinit
```

Le service prend le nom de `acp.name` dans `agent.yaml`, ou `mm` s'il n'y en a pas. Pour le choisir, utilisez `mm dockerinit --name bob`. La suite de ce guide l'appelle `bob`.

Si un fichier existe déjà, mm demande `Overwrite Dockerfile?`, et `no` est la réponse par défaut. Avec `--yes`, ou quand l'entrée se termine, rien n'est écrit.

### Un projet avec un dossier `.mm`

Quand l'agent est `.mm/agent.yaml` (créé avec `mm init --project yes`, voir [ranger les fichiers mini-me d'un projet dans un dossier `.mm`](keep-the-config-in-a-mm-folder.md)), `mm dockerinit` le trouve sans option — il cherche `agent.yaml`, puis `.mm/agent.yaml`, comme mm — et nomme le service d'après lui. `compose.yaml` alors :

- monte `.mm/` **en lecture seule** sur le projet : l'agent ne peut pas modifier ses propres réglages, skills ou hooks ;
- remonte en écriture les dossiers où mm écrit — le `sessions.dir` et le `trace.dir` du fichier d'agent, quand ils sont activés et sous `.mm/` — et les crée tout de suite s'ils n'existent pas (Docker les créerait au nom de root, et l'agent ne tourne jamais en root) ;
- lance `mm tui` sans fichier : mm trouve `.mm/agent.yaml` depuis le projet.

```yaml
    volumes:
      - .:${PWD:-/workspace}
      - ./.mm:${PWD:-/workspace}/.mm:ro
      - ./.mm/sessions:${PWD:-/workspace}/.mm/sessions    # sessions.dir
```

Tout ce qui est écrit d'autre sous `.mm/` — un hook qui y tient un journal — demande sa propre ligne. Après avoir activé ou coupé les sessions ou la trace, relancez `mm dockerinit` (répondez `yes` pour remplacer `compose.yaml`).

## Lancer l'agent

Soit vous gardez un conteneur démarré, qui sert aussi à un éditeur :

```bash
docker compose up -d --wait
docker compose exec bob mm tui agent.yaml
```

Soit vous lancez une session, dans un conteneur qui disparaît avec elle :

```bash
docker compose run --rm bob mm tui agent.yaml
```

Les deux ouvrent le [mode fenêtre](../reference/cli.md) (`mm tui`) et peuvent servir en même temps. Le premier lancement construit l'image.

## Connecter un éditeur (ACP)

Démarrez le conteneur avec `docker compose up -d --wait`, puis donnez cette commande à votre éditeur, avec le chemin absolu du projet :

```bash
docker exec -i bob-box mm --acp --config /chemin/du/projet/agent.yaml
```

Le projet est monté au même chemin que sur votre machine : les chemins envoyés par l'éditeur veulent donc dire la même chose dans le conteneur. Pour un projet `.mm`, `docker exec -i bob-box mm --acp` suffit : le conteneur démarre dans le projet, où mm trouve `.mm/agent.yaml`.

## Joindre le modèle

Depuis le conteneur, `localhost` désigne le conteneur. `dmr`, `llmman` et `ollama` se rabattent d'eux-mêmes sur `host.docker.internal` quand leur adresse par défaut ne répond pas, tant que le fichier d'agent ne définit pas de `baseUrl`. Le fichier compose fait aussi connaître ce nom sous Linux.

- **`llamacpp`** n'a pas ce repli : définissez `baseUrl: http://host.docker.internal:8080/v1`.
- **Un fichier d'agent avec un `baseUrl` sur `localhost` ou `127.0.0.1` :** remplacez l'hôte par `host.docker.internal`, ou ajoutez un `fallback`.
- **Un serveur sous Linux qui n'écoute que sur `127.0.0.1` :** faites-le écouter sur une adresse joignable par le conteneur. `host.docker.internal` y désigne la passerelle de l'hôte, pas sa boucle locale.

## Passer à la dernière version

```bash
docker compose build
docker compose up -d --wait
```

Docker lit le `SHA256SUMS` de la release à chaque build : s'il a changé, les étapes qui installent `mm` sont rejouées.

## Construire pour les deux architectures

`docker compose` construit pour l'architecture de votre machine. Pour publier une image `linux/amd64` et `linux/arm64` :

```bash
docker buildx build --platform linux/amd64,linux/arm64 -t <registry>/mm-bob:latest --push .
```

Construire pour l'autre architecture demande une émulation (QEMU, inclus dans Docker Desktop). Sans elle, le build s'arrête sur `exec format error`.

Une image construite ainsi, hors de compose, donne à son compte `mm` l'uid et le gid 1000. Qui la lance avec d'autres numéros obtient un utilisateur sans nom dans le conteneur : ajoutez `--build-arg MM_UID=… --build-arg MM_GID=…` pour la construire pour lui.

## Utiliser les fichiers sur une autre machine

`compose.yaml` enregistre l'uid et le gid de la machine qui a lancé `mm dockerinit`. Le conteneur tourne sous cet utilisateur, pour que les fichiers créés par l'agent vous appartiennent, et le compte `mm` de l'image est construit avec les mêmes numéros, pour que chaque programme du conteneur sache sous quel utilisateur il tourne — `whoami`, le prompt du shell, ssh. Sur une machine où les vôtres diffèrent, définissez-les, puis reconstruisez l'image :

```bash
export MM_UID=$(id -u) MM_GID=$(id -g)
docker compose up -d --build
```

Sans reconstruction, le conteneur tourne sous votre uid alors que le compte de l'image garde l'ancien : le prompt du shell affiche alors `I have no name!` et `whoami` échoue.

Les fichiers écrits par `mm dockerinit` avant la v1.1.0 construisaient toujours le compte avec l'uid 1000 — sur un Mac, dont l'utilisateur a l'uid 501, le shell affichait `I have no name!`. Relancez `mm dockerinit` (répondez `yes` pour remplacer les deux fichiers), puis `docker compose up -d --build`.

Pour committer, git a toujours besoin d'une identité dans le conteneur : le compte a un nom, mais git n'en déduit pas d'identité. Définissez `user.name` et `user.email` dans le projet (`git config user.name …`), ou passez `GIT_AUTHOR_NAME`, `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_NAME` et `GIT_COMMITTER_EMAIL` au conteneur.

## Ce que le conteneur protège

L'agent ne tourne pas en root, mais il peut quand même modifier et supprimer tout ce qui se trouve dans le projet monté, et il a accès au réseau. Gardez le projet sous gestion de version, et utilisez `yolo: false` si vous voulez approuver chaque commande : voir [confirmer les appels d'outils](confirm-tool-calls.md).

Toutes les options sont dans la [référence CLI](../reference/cli.md#mm-dockerinit--les-fichiers-du-conteneur).