Choisir la base de données et le stockage des médias
SQLite et les fichiers locaux sont utilisés par défaut. Avec Compose, les deux sont conservés dans le volume renewcms-data. Pour l’exécutable autonome, choisissez des chemins stables avec DB_FILE et UPLOAD_DIR. Le compte du service doit pouvoir écrire dans le dossier de données.
PostgreSQL, MySQL et MariaDB permettent d’utiliser une base externe. Un bucket compatible S3 peut stocker les fichiers indépendamment de la base. Consultez la référence /llms/configuration.md de votre instance pour vérifier les variables de votre version avant de changer de stockage.
Configurer PostgreSQL, MySQL ou MariaDB
Créez une base vide et un utilisateur dédié autorisé à créer et migrer son schéma. Définissez DB_DRIVER sur postgres ou mysql (y compris pour MariaDB), puis renseignez DB_HOST, DB_PORT, DB_USER, DB_PASSWORD et DB_NAME. Pour une base distante dotée d’un certificat de confiance, utilisez DB_SSLMODE=verify-full avec PostgreSQL ou DB_TLS=true avec MySQL.
Si la base tourne dans un autre service Compose, DB_HOST correspond au nom de ce service. Le changement de pilote ne déplace pas le contenu existant. Préparez et testez la migration, puis conservez la base d’origine jusqu’à la vérification du nouveau déploiement.
Stocker les médias dans un bucket compatible S3
Créez un bucket privé. Définissez STORAGE_DRIVER=s3, S3_BUCKET et S3_REGION. Pour un service compatible hors AWS, renseignez S3_ENDPOINT et activez S3_PATH_STYLE=true si le fournisseur le demande. Utilisez le rôle du service ou renseignez S3_ACCESS_KEY_ID et S3_SECRET_ACCESS_KEY.
Pour déplacer des fichiers existants, arrêtez RenewCMS et copiez les médias dans le bucket sous les mêmes noms. Si vous définissez S3_KEY_PREFIX, terminez-le par une barre oblique et copiez les fichiers sous ce préfixe. Redémarrez et vérifiez les médias existants avant de supprimer les copies locales.
Sauvegarder votre instance
Conservez une copie de la base, des fichiers, du fichier d’environnement et de la version déployée dans un emplacement sécurisé hors du serveur. Pour SQLite, arrêtez le service avant de copier le dossier ou le volume de données, puis redémarrez-le. Pour une base distante, utilisez son outil de sauvegarde et sauvegardez séparément les fichiers locaux ou le bucket S3.
Avec la configuration Docker par défaut, remplacez VOLUME par le nom réel du volume indiqué par docker volume ls. Lancez ces commandes depuis le dossier Compose et vérifiez que l’archive contient la base SQLite et les médias.
docker compose stop renewcms
docker run --rm -v VOLUME:/data:ro -v "$PWD:/backup" alpine tar czf /backup/renewcms-backup.tar.gz -C /data .
docker compose start renewcmsRestaurer dans une instance de test
Commencez avec un nouveau volume, dossier ou serveur de base de données sur un déploiement séparé. Service arrêté, restaurez la sauvegarde dans les chemins configurés, restaurez les fichiers et attribuez-les au compte du service. Rétablissez la configuration et adaptez PUBLIC_URL et SMTP à l’environnement de test. Lancez la version qui a créé la sauvegarde, puis vérifiez la connexion, les articles et les médias.
Pour un test avec Compose, créez d’abord le conteneur avec docker compose create renewcms. Remplacez RESTORE_VOLUME ci-dessous par le volume de données vide de ce conteneur et lancez l’extraction depuis le dossier de sauvegarde. Démarrez ensuite le service de test.
docker run --rm -v RESTORE_VOLUME:/data -v "$PWD:/backup:ro" alpine \
sh -c 'tar xzf /backup/renewcms-backup.tar.gz -C /data && chown -R 10001:10001 /data'
docker compose start renewcmsMettre à jour en sécurité
Lisez les notes de version et faites une sauvegarde avant la mise à jour. Avec Docker, choisissez le tag voulu, puis téléchargez l’image et recréez le service. Avec l’exécutable, remplacez le fichier puis redémarrez le service. Les migrations se font au démarrage. Vérifiez /healthz et testez l’édition et les routes publiques après la mise à jour.
docker compose pull
docker compose up -dDiagnostiquer le démarrage, la connexion et le courrier
Si /healthz échoue, consultez docker compose logs renewcms ou journalctl -u renewcms -n 50 pour repérer un paramètre manquant ou un stockage inaccessible. Si la connexion fonctionne en local mais échoue via le proxy, vérifiez PUBLIC_URL, HTTPS et les en-têtes du proxy. Pour un courriel manquant, vérifiez les journaux, les identifiants SMTP, l’expéditeur et les indésirables.
Gérer les données des comptes et la conservation
Les utilisateurs peuvent demander un export ou supprimer leur compte depuis leur profil. Vérifiez la conservation du journal dans Paramètres → Activité (90 jours par défaut) et incluez les sauvegardes, la messagerie et tout stockage externe dans l’inventaire des données personnelles.