Les manifestes sont dans le dépôt, sous deploy/kubernetes/. Ils déploient
l'application en un exemplaire, avec un volume persistant, un service et un
ingress.
deploy/kubernetes/
├── 00-namespace.yaml
├── 10-configmap.yaml réglages non secrets
├── 11-secret.example.yaml modèle — ne pas committer sa version renseignée
├── 20-pvc.yaml volume de données
├── 30-deployment.yaml
├── 40-service.yaml
├── 50-ingress.yaml exemple Traefik + cert-manager
└── kustomization.yaml
git clone https://gitlab.ev1.fr/ev1/domodrive.git
cd domodrive/deploy/kubernetes
# 1. le namespace
kubectl apply -f 00-namespace.yaml
# 2. les secrets, créés en ligne de commande plutôt que versionnés
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 Home Assistant>"
# 3. adapter 10-configmap.yaml (URL de Home Assistant, fuseau, mode d'auth)
# et 50-ingress.yaml (nom d'hôte, émetteur de certificat)
# 4. tout le reste
kubectl apply -k .
Suivre le démarrage :
kubectl -n domodrive rollout status deploy/domodrive
kubectl -n domodrive logs deploy/domodrive -f
Les premières lignes du journal montrent les migrations, puis la création des
comptes d'amorçage :
INFO [alembic.runtime.migration] Running upgrade -> 26a2f2fbda52, modeles initiaux
…
WARNING scenario_studio.services.accounts: Comptes d'amorçage créés (admin, admin_dev)
avec le mot de passe par défaut « admin1234 » : le changer dès la première connexion.
Recreatereplicas: 1 n'est pas un oubli. Sur SQLite, deux pods écriraient dans le même
fichier. Et avec un volume ReadWriteOnce, une mise à jour progressive
bloquerait : le nouveau pod attendrait un volume que l'ancien tient encore. D'où
strategy: Recreate.
Pour monter en charge : passer d'abord à PostgreSQL depuis
Administration → Base et sauvegardes (voir Administration),
puis seulement augmenter replicas.
Le point d'entrée de l'image applique alembic upgrade head avant de lancer le
serveur. Il n'y a donc ni Job ni initContainer de migration à orchestrer, et
un alembic upgrade head sur une base déjà à jour ne fait rien.
Conséquence sur les sondes : la sonde de démarrage (startupProbe) tolère
jusqu'à une minute, le temps que les migrations passent sur une base neuve. Les
sondes de vivacité et de disponibilité prennent le relais ensuite.
/health répond sans authentification, teste la base, et n'expose aucun secret :
{"status":"ok","version":"1.0.0","env":"production","auth_mode":"oidc",
"timezone":"Europe/Paris","database":"ok","ha_configured":true}
L'application doit être servie à la racine d'un nom d'hôte
(https://domodrive.exemple.fr/), pas sous un préfixe
(https://exemple.fr/domodrive/) : les URLs qu'elle produit — dont l'URL de
rappel OIDC — sont absolues depuis la racine.
Le conteneur tourne en runAsNonRoot, uid 1000, sans escalade de privilèges et
sans aucune capacité. fsGroup: 1000 fait que le volume est accessible en
écriture par cet utilisateur — sans quoi le pod démarrerait puis échouerait sur
le premier accès à la base.
readOnlyRootFilesystem est laissé à false : l'application écrit dans
/app/data, mais aussi des fichiers temporaires. Le passer à true demande de
monter un emptyDir sur /tmp.
Deux temps, et l'ordre compte.
1. Copier les données. Depuis l'application elle-même :
Administration → Base et sauvegardes → Changer de base. Saisir l'URL cible,
Tester la cible, puis Copier les données vers cette base. La base doit
exister et être vide — l'application ne la crée pas.
2. Basculer. La bascule ne prend effet qu'au redémarrage. Mettre
DATABASE_URL dans le ConfigMap :
DATABASE_URL: "postgresql+asyncpg://domodrive:motdepasse@postgres:5432/domodrive"
Le mot de passe n'a rien à faire dans un ConfigMap : le mettre dans le Secret,
en surchargeant DATABASE_URL côté secret (les valeurs du Secret l'emportent,
envFrom les appliquant après le ConfigMap dans l'ordre déclaré du manifeste).
Puis kubectl -n domodrive rollout restart deploy/domodrive.
Une fois sur PostgreSQL, replicas peut dépasser 1 et le volume n'a plus besoin
d'être ReadWriteOnce — il reste utile pour les sauvegardes, le fichier de
réglages et le journal applicatif.
Deux niveaux, complémentaires :
pg_dump si vous êtes passéLe premier suffit à reconstruire l'application ailleurs ; le second protège du
disque perdu. Ne comptez pas sur celui qui vit dans le volume que vous cherchez
justement à sauver.
Documentation Domodrive 1.0.0 — copie conforme du répertoire docs/ du dépôt gitlab.ev1.fr/ev1/domodrive (dépôt privé).