DoInLab est distribué sous forme d'image Docker publique. Une commande suffit pour l'essayer, un fichier de composition pour l'exploiter sérieusement. Voici les deux chemins, et les réglages à ne pas oublier.
Le dépôt d'images
L'image est publiée sur Docker Hub sous suntux57420/doinlab — hub.docker.com/r/suntux57420/doinlab. Deux étiquettes : latest et la version datée au format AAAA-MM-RRR.
Caractéristiques de l'image : base python:3.12-slim, exécution sous un utilisateur non privilégié, contrôle de santé intégré, et un point d'entrée qui applique les migrations avant de démarrer le serveur.
Essayer en une commande
docker run -d \ --name doinlab \ -p 8000:8000 \ -v doinlab_data:/app/data \ -v doinlab_uploads:/app/uploads \ -v doinlab_logs:/app/logs \ -e SECRET_KEY=changez-cette-cle-secrete \ suntux57420/doinlab:latest
L'application répond sur http://localhost:8000. Compte initial : admin / admin — à changer immédiatement. Tant que ce n'est pas fait, une alerte de sécurité reste affichée dans l'interface, ce qui est une politesse dont il faut tenir compte.
Les trois volumes ne sont pas facultatifs : la base de données, les fichiers téléversés et les journaux vivent dedans. Sans eux, une mise à jour de l'image efface tout.
Installation de production
Un fichier d'environnement à la racine :
SECRET_KEY=une-cle-aleatoire-longue-et-unique DATABASE_URL=sqlite:///./data/doinlab.db LOG_LEVEL=INFO
La clé secrète signe les jetons de session : elle doit être longue, aléatoire et propre à l'installation. La changer déconnecte tout le monde — ce qui est justement l'effet recherché en cas de compromission.
Puis la composition, qui ajoute un moteur de recherche vectorielle utilisé pour la recherche sémantique :
services:
doinlab:
image: suntux57420/doinlab:latest
container_name: doinlab-app
restart: unless-stopped
ports:
- "8000:8000"
volumes:
- doinlab_data:/app/data
- doinlab_uploads:/app/uploads
- doinlab_logs:/app/logs
env_file: [ .env ]
environment:
- ENVIRONMENT=production
- LOG_LEVEL=INFO
depends_on:
qdrant:
condition: service_started
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8000/"]
interval: 30s
networks: [ doinlab_net ]
qdrant:
image: qdrant/qdrant:latest
container_name: doinlab-qdrant
restart: unless-stopped
expose: [ "6333", "6334" ]
volumes:
- qdrant_data:/qdrant/storage
networks: [ doinlab_net ]
volumes:
doinlab_data:
doinlab_uploads:
doinlab_logs:
qdrant_data:
networks:
doinlab_net:
driver: bridge
docker compose up -d docker compose ps docker compose logs -f doinlab
Un point de conception à noter : le moteur vectoriel est exposé au seul réseau interne de la composition, pas à l'hôte. Il n'a aucune raison d'être joignable de l'extérieur, et cette précaution évite d'ouvrir un service sans authentification sur le réseau.
Derrière un reverse-proxy
Pour publier en HTTPS avec un vrai nom de domaine, on place l'application derrière un reverse-proxy — une configuration d'exemple est fournie dans le dépôt. Trois points d'attention :
- transmettre les en-têtes d'origine (hôte, protocole, adresse du client), sans quoi les liens générés et la journalisation seront faux ;
- relever la taille maximale des envois : on téléverse des photos et des documents ;
- ne pas mettre en tampon les réponses du chat en flux — sinon le texte arrive d'un bloc à la fin, et tout l'intérêt du streaming disparaît.
Mettre à jour
docker compose pull docker compose up -d
Au redémarrage, le point d'entrée exécute la migration de schéma : les tables manquantes sont créées, les existantes ne sont pas touchées. Aucune intervention manuelle n'est nécessaire.
La prudence élémentaire reste de mise : sauvegarder le volume de données avant une montée de version. La base étant un fichier, cela revient à le copier.
Après le premier démarrage : le tableau de bord répond, et tout le reste se règle depuis l'administration — sans toucher au serveur.
Ce qui se configure ensuite, dans l'interface
L'installation ne demande rien d'autre. Tout le reste se règle dans l'administration :
- l'IA — URL du serveur, clé éventuelle, modèle de texte, modèle de vision, température. Tout serveur compatible avec l'API OpenAI convient : un modèle local via Ollama, LM Studio, ou un service en ligne. Sans configuration, l'application fonctionne — simplement sans les enrichissements ;
- la messagerie — serveur d'envoi et modèles de messages, avec un test de connexion qui n'envoie rien ;
- l'authentification unique — n'importe quel fournisseur OpenID Connect, avec découverte automatique. L'adresse de retour à déclarer chez le fournisseur est
https://votre-domaine/auth/oidc/callback; - GitLab — pour créer un dépôt depuis un projet ; nécessite un jeton avec les droits d'écriture ;
- les catégories d'inventaire, le nom de l'organisation, l'ouverture des inscriptions, et le mode maintenance.
Développement local
python3 -m venv .venv && source .venv/bin/activate pip install -r requirements.txt cp env.example .env uvicorn app.main:app --reload --host 0.0.0.0 --port 8000
Pas de base à installer, pas de service annexe obligatoire : SQLite est un fichier, et l'application crée ses répertoires au démarrage. C'est l'un des avantages pratiques du choix de pile — on est opérationnel en trois commandes.
Vérifications après installation
- l'application répond, et le contrôle de santé du conteneur est au vert ;
- le mot de passe administrateur a été changé — l'alerte a disparu ;
- un envoi de photo fonctionne : c'est ce qui valide les volumes et le traitement d'images ;
- si l'IA est configurée, une génération de description aboutit ;
- les journaux d'activité se remplissent.
Cinq minutes de contrôle qui évitent de découvrir un volume mal monté le jour où l'inventaire compte deux cents fiches.
La série DoInLab
- DoInLab : la solution en un coup d'œil
- Le parcours fonctionnel, écran par écran
- L'architecture technique
- Installer DoInLab avec Docker — vous y êtes
Image publique : suntux57420/doinlab sur Docker Hub — hub.docker.com/r/suntux57420/doinlab.