Guide de mise à niveau¶

Procédure de mise à niveau de Repod sous Docker Compose.

Sauvegardez avant de mettre à niveau

Exécutez toujours une sauvegarde avant une mise à niveau. Voir Sauvegarde & restauration →

Avant de commencer¶

Consultez le changelog pour les changements incompatibles : Changelog →
Passez en revue les notes de migration dans les notes de version de la version cible.
Planifiez une fenêtre de maintenance — la mise à niveau provoque ~30 secondes d'indisponibilité pendant le redémarrage des conteneurs.

Procédure de mise à niveau standard¶

cd /opt/repod

# Étape 1 — Sauvegarder les données
./backup.sh

# Étape 2 — Récupérer la nouvelle version
git fetch origin
git pull origin main

# Étape 3 — Arrêter les services
docker compose down

# Étape 4 — Reconstruire les images
docker compose build --no-cache

# Étape 5 — Démarrer les services
docker compose up -d

# Étape 6 — Vérifier le démarrage
docker compose ps
curl http://localhost:8000/health/live

Vérifier la version déployée¶

curl -s http://localhost:8000/health/live | jq .version
# ou : Paramètres → À propos dans l'interface web

Mise à niveau vers une version spécifique¶

# Lister les tags disponibles
git tag -l | sort -V | tail -10

# Basculer sur la version cible
git checkout v1.3.0

# Reconstruire et redémarrer
docker compose down
docker compose build --no-cache
docker compose up -d

Revenir en arrière (rollback)¶

Si un problème est découvert après une mise à niveau :

cd /opt/repod

# 1. Arrêter les services
docker compose down

# 2. Revenir à la version précédente
git log --oneline -10
git checkout <tag-ou-commit-precedent>

# 3. Reconstruire et redémarrer
docker compose build --no-cache
docker compose up -d

# 4. Vérifier
docker compose ps
curl http://localhost:8000/health/live

Migrations de base de données

Repod utilise PostgreSQL avec des migrations de schéma Alembic appliquées automatiquement au démarrage. Revenir à une version qui ne comprend pas le nouveau schéma est sûr tant qu'aucune nouvelle colonne n'a été écrite par la version plus récente. Si le rollback échoue à démarrer, restaurez la base PostgreSQL (pg_restore) depuis votre sauvegarde — voir Sauvegarde & Restauration.

Mise à niveau des variables d'environnement¶

Quand une nouvelle version introduit de nouvelles variables d'environnement :

Consultez les notes de version pour les variables nouvelles ou modifiées.
Consultez la référence des variables d'environnement →.
Mettez à jour backend.env et/ou .env avant de reconstruire :

# Comparer votre backend.env actuel à l'exemple
diff backend.env backend.env.example

# Ajouter toute nouvelle variable avec sa valeur par défaut
nano backend.env

Reconstruire le frontend après un changement d'URL¶

Si REACT_APP_API_URL ou REACT_APP_REPO_URL ont changé dans .env :

docker compose build frontend-ui
docker compose up -d frontend-ui

Les variables React sont intégrées au bundle JavaScript au moment du build — elles ne prennent effet qu'après la reconstruction de l'image.

Migrations de base de données¶

Repod applique les migrations de schéma PostgreSQL automatiquement au démarrage via alembic. Aucune étape manuelle n'est nécessaire en fonctionnement normal.

Vérifier que les migrations se sont bien appliquées :

docker compose logs backend-api | grep -i "alembic\|migration\|migrate"
# Attendu : "Running upgrade ... OK" pour chaque migration en attente

Si les migrations échouent :

# Vérifier l'historique des migrations
docker exec backend-api alembic history

# Vérifier la révision actuelle
docker exec backend-api alembic current

# Forcer une révision spécifique (à n'utiliser qu'en dernier recours)
docker exec backend-api alembic upgrade head

Mises à jour des bases ClamAV et Grype¶

Les bases de vulnérabilités ClamAV et Grype sont mises à jour automatiquement — aucune action de mise à niveau n'est requise. Pour forcer une mise à jour immédiate après une mise à niveau :

TOKEN=$(curl -s -X POST http://localhost:8000/api/v1/auth/token \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"YourPassword!"}' | jq -r .access_token)

# Forcer la mise à jour ClamAV
curl -X POST -H "Authorization: Bearer $TOKEN" \
  http://localhost:8000/api/v1/security/clamav/update

# Grype se met à jour automatiquement lors du prochain scan (ou au démarrage si > 24h)
docker exec backend-api grype db update

Notes de migration par version¶

v1.x → v2.x (prévu)¶

Redis sera requis pour la révocation des jetons JWT (optionnel en v1.x).
La variable d'environnement REDIS_URL devra être ajoutée à backend.env.
Exécutez docker compose build --no-cache — l'image de base change.

v1.1.x → v1.2.x¶

Aucun changement incompatible. Suivez la procédure de mise à niveau standard.

v1.0.x → v1.1.x¶

Nouvelle variable d'environnement : GRYPE_DB_CACHE_DIR (défaut : /repos/grype-db). Ajoutez-la à backend.env si vous avez des chemins de stockage personnalisés.
Le répertoire /repos/grype-db/ est créé automatiquement au premier démarrage.