Tableau de bord de Domodrive 1.0.0
Technologie

Domodrive 1.0.0 : la version qu'on peut enfin installer chez soi

Quatre articles ont raconté pourquoi cette application existe et comment elle est faite. Celui-ci rassemble tout le reste : l'image Docker publiée, les manifestes Kubernetes, la documentation complète, et la marche à suivre pour l'installer chez soi en quelques minutes.

Guillaume Evain 17 août 2026
5 min de lecture 23 vues
Python Kubernetes Architecture Docker Automatisation

Domodrive est un atelier de conception de scénarios domotiques pour Home Assistant. On y dessine des plannings horaires d'actions sur les volets et les éclairages, on les valide, on les déploie sur une plage de dates, puis on les retire sans laisser de trace. Le cas d'usage fondateur tient en une phrase : partir deux semaines en vacances avec une simulation de présence crédible.

Quatre articles ont déjà été consacrés au sujet. Ils racontent le pourquoi et le comment c'est fait. Il manquait le reste : comment on l'installe, où on trouve la documentation, et ce qu'il faut savoir avant de lancer la première commande. C'est l'objet de celui-ci, qui sert aussi de point d'entrée unique vers tout le reste.

Les quatre épisodes précédents

Dans l'ordre de lecture conseillé :

Si vous n'en lisez qu'un, prenez le premier : il montre ce que l'application fait. Les trois autres expliquent comment elle le fait.

Ce que la 1.0.0 apporte

Le code n'a pas beaucoup changé — il était déjà couvert par des dizaines de tests. Ce qui change, c'est tout ce qui entoure le code :

  • une image Docker publiée, suntux57420/domodrive:1.0.0, également disponible en :latest ;
  • des manifestes Kubernetes prêts à appliquer, dans deploy/kubernetes/ ;
  • une documentation complète en treize pages, publiée sur le wiki (wiki.ev1.fr) ;

Installer avec Docker

La version la plus courte, pour essayer :

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, compte admin, mot de passe admin1234 — que l'application réclame de changer dès la première connexion, et dont elle continue de se plaindre par un bandeau rouge tant que c'est encore la valeur par défaut.

Tableau de bord de Domodrive 1.0.0

Le tableau de bord au premier lancement : rien n'est encore déployé, la liaison avec Home Assistant est établie et inventoriée, et l'application rappelle en pied de page ce qu'elle ne fera jamais — piloter les équipements elle-même.

Deux pièges qui coûtent une soirée

Quatre slashes, pas trois. sqlite+aiosqlite:////app/data/… désigne le chemin absolu /app/data/…. Avec trois slashes, le chemin devient relatif au répertoire de travail : la base n'est plus dans le volume, et elle disparaît au remplacement du conteneur. On ne s'en aperçoit qu'à la première mise à jour, c'est-à-dire au pire moment.

Le 127.0.0.1 d'un conteneur, c'est le conteneur. Si Home Assistant tourne sur le même hôte, il faut host.docker.internal dans HA_BASE_URL, et l'entrée extra_hosts correspondante sous Linux. Le docker-compose.yml du dépôt la contient déjà.

Ce que contient le volume

Tout ce qui doit survivre au remplacement du conteneur vit dans /app/data : la base SQLite, le fichier de réglages settings.json — jeton Home Assistant chiffré compris —, les archives de sauvegarde, le journal applicatif, le snapshot de mise à jour au besoin.

C'est donc le seul répertoire à sauvegarder.

Sur Kubernetes

Les manifestes sont dans le dépôt : namespace, ConfigMap, modèle de Secret, PVC, Deployment, Service, Ingress Traefik, et un kustomization.yaml pour appliquer l'ensemble.

kubectl apply -f deploy/kubernetes/00-namespace.yaml

kubectl -n domodrive create secret generic domodrive \
  --from-literal=SECRET_KEY="$(python3 -c 'import secrets; print(secrets.token_urlsafe(48))')" \
  --from-literal=HA_TOKEN="<jeton longue durée>"

kubectl apply -k deploy/kubernetes/

Deux choix méritent d'être explicités, parce qu'ils surprennent au premier regard :

replicas: 1. Sur SQLite, deux pods écriraient dans le même fichier. Pour monter en charge, il faut d'abord passer à PostgreSQL — l'écran d'administration copie les données et teste la cible avant de basculer — et ensuite seulement augmenter le nombre d'exemplaires.

strategy: Recreate. Avec un volume ReadWriteOnce, une mise à jour progressive se bloquerait : le nouveau pod attendrait un volume que l'ancien tient encore. Autant l'assumer explicitement plutôt que de découvrir un rollout figé.

Les trois sondes pointent sur /health, qui répond sans authentification et n'expose aucun secret. La sonde de démarrage tolère une minute, le temps que les migrations passent sur une base neuve.

La documentation

La documentation est publiée sur le wiki : présentation, installation Docker, installation Kubernetes, configuration et options, authentification et rôles, prise en main, plannings, routines de contrôle, périodes et déploiement, administration, exploitation et dépannage, référence technique.

Elle est illustrée des captures produites sur un jeu de démonstration. Le simulateur interne sert d'instance Home Assistant.

👉 Documentation Domodrive

Tout au même endroit

Et les quatre articles de la série, rappelés plus haut, pour la partie qui n'est pas dans la documentation : les raisons.

La suite

Le prochain chapitre est déjà écrit dans deploy/kubernetes/ : faire tourner Domodrive sur le cluster k3s de la maison et le passage à PostgreSQL.

D'ici là, l'image est publique, la documentation est en ligne, et il suffit d'une commande pour l'essayer.

Retour au blog