Lancer Ollama dans Docker est pratique pour isoler le service, mais il faut être précis sur l’image, le volume, le port et le réseau. En production, évitez de raisonner en “latest pour toujours”. Choisissez une version ou un digest quand la reproductibilité compte, notez l’image utilisée et testez la mise à jour séparément.
Repère documentaire : documentation officielle du fonctionnement présenté.
Démarrage CPU local
docker volume create ollama
docker run -d --name ollama -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 ollama/ollamaLe bind sur 127.0.0.1 limite l’exposition à la machine hôte. Publier 11434:11434 sur toutes les interfaces peut rendre le service accessible depuis le réseau selon le pare-feu. Après démarrage, vérifiez localement :
curl --max-time 10 http://127.0.0.1:11434/api/tagsSi vous obtenez une liste JSON de modèles, l’API répond. Si la liste est vide, ce n’est pas une erreur : aucun modèle n’a encore été téléchargé.
Conflits courants
- Nom déjà pris : un conteneur
ollamaexiste déjà. Utilisezdocker ps -a, puis stop/restart si vous voulez le conserver. - Port occupé : un service Ollama natif ou un autre conteneur utilise déjà 11434.
- Perte de modèles : supprimer le conteneur ne supprime pas le volume, mais supprimer le volume efface les modèles.
- localhost depuis un autre conteneur :
localhostpointe vers le conteneur appelant, pas vers Ollama. Utilisez un réseau Docker et le nom de service.
Stop, restart, rm : choisir la bonne action
docker stop ollama
docker start ollama
docker restart ollama
# docker rm ollama seulement si vous voulez supprimer le conteneurNe commencez pas par rm quand un simple restart suffit. Le volume nommé garde les modèles, mais les options de lancement du conteneur peuvent être perdues si vous recréez à la main sans les noter.
GPU Linux et Mac
Sur Linux avec NVIDIA, l’approche Docker demande le NVIDIA Container Toolkit et un lancement avec accès GPU selon la documentation de votre version Docker. Sur Mac, Docker Desktop ne donne pas un accès NVIDIA/Metal natif équivalent à un Ollama installé directement sur macOS. Pour exploiter Metal, l’installation native macOS est généralement le chemin à tester plutôt qu’un conteneur Linux.
Exemple autre conteneur
docker network create ai-net
docker network connect ai-net ollama
# un conteneur applicatif sur ai-net appellera http://ollama:11434/api/tagsLa bonne validation n’est pas seulement “le conteneur tourne”. Il faut vérifier /api/tags, télécharger un modèle, lancer une génération courte, noter l’image utilisée et documenter comment arrêter sans perdre le volume.
Télécharger et tester un modèle
Une fois le conteneur lancé, téléchargez un modèle depuis le conteneur ou via l’API selon votre procédure. Exemple documentaire : docker exec ollama ollama pull llama3.2. Ensuite, testez une génération très courte avant de brancher une application. Si ce test échoue, n8n, votre app ou votre proxy ne sont pas encore en cause.
Versionner le run
Conservez dans un fichier d’exploitation : image utilisée, options de port, volume, réseau Docker, activation GPU, commande de pull et méthode de mise à jour. Si vous changez l’image, testez d’abord sur un autre nom de conteneur ou une machine de staging. Une mise à jour peut modifier les performances, la compatibilité modèle ou les logs.
Accès réseau maîtrisé
Pour un usage depuis une application sur la même machine, 127.0.0.1 suffit. Pour un autre conteneur, utilisez un réseau Docker. Pour une autre machine, placez un reverse proxy authentifié ou un tunnel contrôlé. Exposer Ollama brut sur un réseau partagé est rarement une bonne idée.
Docker Compose minimal
Pour une installation durable, Compose évite d’oublier les options de lancement. Exemple documentaire : service ollama, image à versionner avant production, volume nommé ollama, port lié à 127.0.0.1. Si vous ajoutez une application dans le même Compose, faites-la appeler http://ollama:11434 via le réseau interne plutôt que le port hôte.
services:
ollama:
image: ollama/ollama
ports:
- "127.0.0.1:11434:11434"
volumes:
- ollama:/root/.ollama
volumes:
ollama:Ce fichier reste volontairement minimal : ajoutez GPU, version ou digest selon votre contexte, mais ne mélangez pas toutes les options tant que le test CPU local n’est pas validé.
Critère de réussite
Le critère final est concret : le conteneur redémarre, le volume conserve les modèles, /api/tags répond, une génération courte fonctionne et une autre application sait joindre le bon host. Tant que ces cinq points ne sont pas vrais, ne branchez pas le service à une automatisation métier.
Test d’appel depuis une application
Après le test local, lancez un conteneur temporaire sur le même réseau et appelez http://ollama:11434/api/tags. Ce contrôle prouve que le problème réseau est réglé avant d’impliquer votre code applicatif. Si l’appel échoue, corrigez le réseau Docker plutôt que le prompt.
Runbook de maintenance
Notez la commande de mise à jour, la procédure de retour arrière et le volume à ne pas supprimer. Le jour où le conteneur ne redémarre pas, cette note vaut plus qu’un historique shell incomplet.
Santé du volume
Contrôlez l’espace disque disponible avant de télécharger plusieurs modèles. Un volume plein peut provoquer des erreurs de pull ou des modèles incomplets difficiles à diagnostiquer ensuite.
Pour les bases : définition d’un modèle de langage.
