L'image publiée contient tout : l'application, ses migrations et son point
d'entrée. Elle applique alembic upgrade head au démarrage, ce qui la rend
utilisable telle quelle sur un volume vide.
| Image | suntux57420/domodrive:1.0.0 — également publiée en :latest |
| Base | python:3.12-slim, image multi-étapes |
| Utilisateur | app (uid 1000), non privilégié |
| Port exposé | 8000 |
| Volume de données | /app/data |
| Sonde de santé | GET /health toutes les 30 s, intégrée à l'image |
docker run -d --name domodrive \
-p 8000:8000 \
-v domodrive-data:/app/data \
-e SECRET_KEY="$(python3 -c 'import secrets; print(secrets.token_urlsafe(48))')" \
-e DATABASE_URL="sqlite+aiosqlite:////app/data/scenario_studio.db" \
-e HA_BASE_URL="http://homeassistant.local:8123" \
-e HA_TOKEN="<jeton longue durée>" \
suntux57420/domodrive:1.0.0
Puis http://localhost:8000, identifiant admin, mot de passe admin1234 —
à changer immédiatement, l'application le réclame dès la première connexion.

Quatre slashes, pas trois.
sqlite+aiosqlite:////app/data/…désigne le
chemin absolu/app/data/…. Avec trois slashes, le chemin serait relatif au
répertoire de travail et la base ne serait pas dans le volume : elle
disparaîtrait au remplacement du conteneur.
C'est la forme à retenir : la configuration vit dans un fichier, pas dans un
historique de shell.
services:
app:
image: suntux57420/domodrive:1.0.0
container_name: domodrive
restart: unless-stopped
ports:
- "8000:8000"
env_file:
- .env
environment:
DATABASE_URL: sqlite+aiosqlite:////app/data/scenario_studio.db
volumes:
- ./data:/app/data
extra_hosts:
- "host.docker.internal:host-gateway"
cp .env.example .env # puis renseigner les valeurs
docker compose up -d
docker compose logs -f # suivre le démarrage et les migrations
Le fichier .env.example du dépôt documente chaque variable ; la page
Configuration et options les reprend une à une.
Le 127.0.0.1 d'un conteneur, c'est le conteneur lui-même. Utiliser
host.docker.internal dans HA_BASE_URL — d'où la directive extra_hosts
ci-dessus, nécessaire sous Linux.
HA_BASE_URL=http://host.docker.internal:8123
Tout ce qui doit survivre au remplacement du conteneur :
| Chemin | Contenu |
|---|---|
data/scenario_studio.db |
la base SQLite |
data/settings.json |
les réglages modifiables depuis l'interface, secrets chiffrés |
data/sauvegardes/ |
les archives JSON de sauvegarde |
data/logs/ |
le journal applicatif, en rotation par taille |
data/dev_snapshot.json |
la photographie du mode développement, s'il a servi |
data/dev_automations.json |
les automatisations écrites dans le simulateur |
Sauvegardez ce répertoire. Une archive prise depuis l'écran d'administration
et laissée dans data/sauvegardes/ ne protège pas d'un disque perdu : elle est
sur le même disque.
docker compose pull
docker compose up -d
Les migrations s'appliquent au démarrage du nouveau conteneur. Prenez une
sauvegarde avant (Administration → Base et sauvegardes → Sauvegarder
maintenant), et récupérez le fichier : une montée de version est exactement le
moment où l'on regrette de ne pas l'avoir fait.
git clone https://gitlab.ev1.fr/ev1/domodrive.git
cd domodrive
docker build -t domodrive:1.0.0 .
Le Dockerfile est en deux étapes : les dépendances s'installent avant le code,
de sorte que le cache de couches survit à une modification de source.
curl -s http://localhost:8000/health
{"status":"ok","version":"1.0.0","env":"production","auth_mode":"local",
"timezone":"Europe/Paris","database":"ok","ha_configured":true}
C'est aussi l'URL utilisée par la sonde de santé de l'image, et celle à donner à
un superviseur externe. Elle ne demande aucune authentification et n'expose
aucun secret.
Depuis le conteneur, sans rien modifier :
docker compose exec app python -m scenario_studio.diagnose
Le diagnostic vérifie chaque maillon l'un après l'autre — instance joignable,
jeton accepté, composants chargés, API WebSocket et registres — et dit lequel ne
répond pas. Voir Exploitation et dépannage.
Documentation Domodrive 1.0.0 — copie conforme du répertoire docs/ du dépôt gitlab.ev1.fr/ev1/domodrive (dépôt privé).