OpenCode avec Docker : exécuter et vérifier un conteneur

Réponse rapide : choisir le chemin Docker

Docker Sandbox convient à une première zone de travail isolée, mais il faut connaître les fichiers montés, le fournisseur qui reçoit le code et les permissions du sandbox.

Docker Model Runner fournit le service de modèle, tandis qu'OpenCode reste l'interface. Un endpoint actif ne règle pas le montage ni les permissions.

Une image personnalisée fixe Node et les paquets, mais demande la maintenance du Dockerfile, de l'utilisateur, des mises à jour et des secrets.

Chemins de configuration et compromis

`opencode docker image`, `opencode docker compose` et `docker opencode` sont des variantes d'une même décision. Un tableau suffit, sans créer plusieurs pages.

Pour un dépôt simple, partez de l'image minimale qui exécute le CLI et atteint le fournisseur. N'ajoutez pas de services ni le dossier personnel avant le premier test.

Si Docker sert la confidentialité du modèle, séparez le service d'inférence de l'agent de code. L'endpoint ne remplace pas la revue du montage.

Avant d'exécuter OpenCode dans un conteneur

Examinez l'origine de l'image avant de monter le code. Préférez une documentation officielle ou un Dockerfile vérifiable.

Montez seulement le projet; évitez home, clés SSH, identifiants cloud et socket Docker de l'hôte.

Injectez les identifiants au démarrage, jamais dans Dockerfile, couches, Compose versionné ou historique shell; contrôlez `.dockerignore`.

Commencez par un petit dépôt, une lecture, un petit changement, un diff Git et un test sans effet production.

7 contrôles pour une configuration fiable

Ces contrôles transforment le lancement en preuve : modèle absent vers endpoint, fichiers absents vers montage, écriture excessive vers permissions.

Gardez le même ordre sur ordinateur et en CI et notez image, fournisseur, chemin et commande.

Une réponse réussie ne prouve pas la sécurité si l'image ou le volume est trop large.

1. Inspecter l'image Notez nom, tag ou digest, base, mise à jour et utilisateur.
2. Réduire l'espace Montez le projet et utilisez branche ou worktree séparé.
3. Connecter un fournisseur Validez un endpoint et gardez la clé hors dépôt.
4. Confirmer le modèle Vérifiez réponse, ID, contexte et port.
5. Tâche en lecture Demandez un résumé avant les changements.
6. Revoir un petit diff Modifiez documentation ou fixture et refusez les fichiers étrangers.
7. Nettoyer Arrêtez le conteneur, supprimez les volumes temporaires et notez le correctif.

Docker Model Runner et endpoints compatibles OpenAI

Docker Model Runner convient à l'inférence locale ou privée. Activez un modèle, vérifiez le service depuis le même réseau et utilisez l'URL et l'ID exacts.

Testez séparément l'endpoint et la tâche OpenCode, puis contrôlez contexte, permissions et session.

Limitez interface et ports et indiquez passerelle hôte, service Compose ou serveur distant.

# Illustrative shape only; confirm current image, endpoint, and model fields in official docs
docker run --rm -it --mount type=bind,src="$PWD",dst=/workspace --workdir /workspace -e OPENAI_API_KEY -e OPENAI_BASE_URL opencode-image:reviewed opencode

Permissions, secrets, ports et Git

La frontière du conteneur n'est qu'une partie des permissions. OpenCode, Docker, l'utilisateur Linux, le fournisseur et Git doivent rester cohérents.

Documentez commande minimale, nettoyage, volumes, ports privés et reproduction de l'image.

La première écriture doit rester petite; arrêtez-vous en cas de secrets ou de fichiers hors dépôt.

Dépannage : isoler la couche en échec

Si `opencode` manque, vérifiez image, PATH, entrypoint et utilisateur avant de modifier le fournisseur.

Si le modèle manque, testez l'endpoint depuis le conteneur et vérifiez URL, DNS, port, identifiants et ID; `localhost` peut désigner le conteneur.

Si l'édition est mauvaise, réduisez montage et portée, refaites une tâche de lecture et notez digest, modèle et diff.