Organisation, validation et guide d’exploitation
Placez chaque service dans son propre répertoire inspecté. Pour un nouveau projet, examinez d’abord /srv et confirmez que le répertoire prévu n’existe pas :
ls -ld /srv
sudo find /srv -mindepth 1 -maxdepth 2 -printf '%M %u:%g %p\n'
# Créer uniquement un chemin absent, sans lien symbolique ni montage.
sudo mkdir -- /srv/example-api &&
sudo chown -- "$VPS_USER:$VPS_USER" /srv/example-api
L’absence volontaire de -p fait échouer mkdir si le chemin existe ; && empêche alors le changement de propriétaire. Vérifiez que $VPS_USER désigne le compte de déploiement voulu et que son groupe homonyme existe. Sur un hôte partagé, protégez aussi la création contre les modifications concurrentes.
N’exécutez jamais chown -R sur tout /srv. Un changement récursif de propriétaire touche aussi les données : les volumes des conteneurs peuvent exiger un UID/GID numérique particulier, et les sauvegardes un accès réservé à root. Pour un projet existant, vérifiez les exigences du service avant de modifier un chemin précis. Un répertoire /srv/backups vide n’est pas un système de sauvegarde ; il faut des planifications, des versions, des copies hors site et des tests de restauration.
systemctl is-active vérifie si un service fonctionne actuellement ; is-enabled vérifie s'il démarre au démarrage du système. Diagnostiquez avec :
systemctl --failed --no-pager
sudo journalctl -u docker --since today --no-pager
sudo journalctl -u tailscaled --since today --no-pager
Masquez les données sensibles dans les journaux avant de les partager. Pour les mises à jour, exécutez apt update, inspectez apt list --upgradable, puis apt upgrade. Simulez les modifications automatisées risquées avec apt-get -s. Les mises à jour ordinaires progressives peuvent être reportées intentionnellement.
Vérifiez /var/run/reboot-required ; avant de redémarrer, vérifiez l'accès Tailscale, conservez une session active, redémarrez délibérément, reconnectez-vous, puis revérifiez le noyau et les unités en échec.
Liste de contrôle de validation
hostnamectl; timedatectl
nproc; free -h; df -h /
ip -brief addr; ip route
tailscale status; tailscale ip -4
sudo ufw status verbose
sudo sshd -t
sudo sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|authenticationmethods) '
docker --version; docker compose version
systemctl is-active docker tailscaled
docker info
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}\t{{.Status}}'
docker compose -f /srv/caddy/compose.yaml ps
docker compose -f /srv/uptime-kuma/compose.yaml ps
docker compose -f /srv/rsshub/compose.yaml ps
docker network inspect infra-edge
systemctl --failed --no-pager
find /srv -maxdepth 2 -printf '%M %u:%g %p\n' | sort
Comparez les valeurs SSH avec la politique d’accès par clé seule, y compris les blocs Match applicables. Depuis WSL2, une nouvelle session SSH via Tailscale doit réussir et une nouvelle tentative SSH via l'IP publique doit échouer. Les deux URL de santé HTTPS publiques doivent valider normalement leur certificat, tandis que les requêtes directes publiques et via Tailscale vers le port 1200 de RSSHub doivent échouer.
Une simple mention 1200/tcp dans docker ps n'est qu'un port interne à l'image. Une publication sur l'hôte ressemble à 0.0.0.0:1200->1200/tcp et invaliderait cette conception. L'état accepté est Caddy sur les ports 80/443 de l'hôte, Kuma exactement sur 127.0.0.1:3001, et aucune liaison d'hôte pour RSSHub.
Après chaque déploiement, vérifiez le service concerné, UFW et docker ps ; chaque semaine, vérifiez les mises à jour, les unités en échec, le disque et les conteneurs ; chaque mois, passez en revue les appareils du tailnet, les clés, les ports exposés et l'accroissement des journaux.
Lors d'un incident : préservez l'accès, arrêtez d'élargir le changement, identifiez la couche défaillante, collectez des preuves sans secrets, restaurez l'état sûr le plus proche et vérifiez le rétablissement avec une nouvelle connexion ou une requête complète. Utilisez Tmux pour les travaux de longue durée, mais rappelez-vous qu'il survit aux déconnexions SSH, pas aux redémarrages de l'hôte.
Les trois projets Compose actuels — Caddy, Uptime Kuma et RSSHub — ont des cycles de vie indépendants. Opérez depuis le répertoire /srv/<service> correspondant, inspectez d'abord docker compose ps et les journaux, et n'utilisez jamais de nettoyage global Docker (prune) comme procédure de dépannage de routine. Le déploiement miroir de RSSHub gère les détails relatifs à l'image, à ACCESS_KEY, au canari et au retour arrière. Le consommateur de flux existant, ses données persistantes et son planificateur n'ont pas encore été migrés.